Menu
▾
▴
[Bacula-bugs] [bacula 0000265]: Lots of 'Got EOF at file ...' messages and slow restore
|
From: <bac...@li...> - 2005-03-18 15:35:31
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000265 ====================================================================== Reported By: stark Assigned To: ====================================================================== Project: bacula Bug ID: 265 Category: Storage Daemon Reproducibility: always Severity: major Priority: normal Status: closed ====================================================================== Date Submitted: 03-17-2005 23:59 PST Last Modified: 03-18-2005 07:35 PST ====================================================================== Summary: Lots of 'Got EOF at file ...' messages and slow restore Description: Restores with bacula 1.36.2 are very slow when the fileset spans multiple volumes. After restoring from the first tape bacula seems stuck spweing out 'Got EOF at file ...' messages like this: 15-Mar 11:05 yangtse-sd: Got EOF at file 71 on device /dev/rmt/0cbn, Volume "000014" 15-Mar 11:05 yangtse-sd: Got EOF at file 72 on device /dev/rmt/0cbn, Volume "000014" 15-Mar 11:05 yangtse-sd: Got EOF at file 73 on device /dev/rmt/0cbn, Volume "00001 [...] ====================================================================== ---------------------------------------------------------------------- chemical - 03-18-2005 00:43 PST ---------------------------------------------------------------------- I'm quite sure this is a follow up issue to the fix of http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000227 If I look into your attached patch there, you commented out "dev->state |= ST_EOT;", which looks like it can answer the problem rised here: The drive seems to read until the EOM before it stops restoring. Thats why stark reported very slow restores. The restores itself are very fast, but the tape reads and reads further until a state change (EOM for example). That would explain the informational "overread" EOFs which were printed in starks report (I have them too). At least this is the behaviour here (which is new since 1.36.2, too). If I start a restore job which needs to restore 2 files from 2 volumes (autochanger in place), it mounts the first volume, forward spaces to the right file:block and restores the file. Instead of then ejecting the volume and restore from the next volume, it reads the first volume till the end (slow restore) and then suddenly notices (upon EOM in my case) that it reads the wrong volume: Warning: Wrong Volume mounted on device /dev/nst0: Wanted L1470001 have L1470010 Then it unmounts, mounts the correct one and completes the restore job. So far no show stopper, but it looks like the quick fix was not the best way to solve the bug. Hope this helps Roland ---------------------------------------------------------------------- kern - 03-18-2005 01:00 PST ---------------------------------------------------------------------- Thanks for noticing the problem and reporting it. Please try the attached patch. The instructions for applying it are at the top of the file. Your feedback would be appreciated. ---------------------------------------------------------------------- chemical - 03-18-2005 01:29 PST ---------------------------------------------------------------------- If someone can provide updated rpm's for SuSE 9.2 I can test it ---------------------------------------------------------------------- stark - 03-18-2005 05:47 PST ---------------------------------------------------------------------- The attached patch fixes the problem. I applied it, recompiled bacula, installed it and tried to restore the same fileset that failed before. I compared md5 sums of the original and the restored files, just to be very sure. Thank you for being so quick. ---------------------------------------------------------------------- kern - 03-18-2005 07:35 PST ---------------------------------------------------------------------- OK, thanks for testing. Concerning rpms -- they will have to wait for the next release, or you can rebuild them from source, but you need to edit the .spec file to include the patch. Bug History Date Modified Username Field Change ====================================================================== 03-17-05 23:59 stark New Bug 03-17-05 23:59 stark File Added: restore.bsr.txt 03-17-05 23:59 stark Bug Monitored: stark 03-18-05 00:43 chemical Bugnote Added: 0000780 03-18-05 00:58 kern File Added: 1.36.2-restore-speed.patch 03-18-05 01:00 kern Bugnote Added: 0000781 03-18-05 01:00 kern Status new => feedback 03-18-05 01:29 chemical Bugnote Added: 0000783 03-18-05 05:47 stark Bugnote Added: 0000784 03-18-05 07:35 kern Bugnote Added: 0000787 03-18-05 07:35 kern Resolution open => fixed 03-18-05 07:35 kern Status feedback => closed ====================================================================== |