Hi, As I read it, I realize that I can report the same behaviour. I assume that this is because of the subtle fix of http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000227
It looks like bacula now reads all following data on that tape, too - until it reaches its end: 16-Mar 12:03 ueun33-sd: Forward spacing to file:block 134:0. nagios-fd: -r--r--r-- 1 wwwrun root 106354 2005-03-14 16:08:00 /tmp/restore/etc/nagios/services.cfg 16-Mar 12:07 ueun33-sd: End of Volume at file 157 on device /dev/nst0, Volume "L1470010" 16-Mar 12:08 ueun33-sd: RestoreFiles.2005-03-16_12.01.07 Warning: Wrong Volume mounted on device /dev/nst0: Wanted L1470001 have L1470010 16-Mar 12:08 ueun33-sd: 3301 Issuing autochanger "loaded drive 0" command. This is new behaviour compared to 1.36.1 and perhaps answers the problem of the very, very long taking restores since .2 I'm using Scotts RPMs on a SuSE 9.2 system. Thanks Roland -----Urspr�ngliche Nachricht----- Von: Kern Sibbald [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. M�rz 2005 18:33 An: Sebastian Stark Cc: [email protected]; Roland Arendes Betreff: Re: AW: [Bacula-users] 1.36.2, "Got EOF at file ...", Solaris 10 On Wednesday 16 March 2005 17:25, Sebastian Stark wrote: > Hi, > > Thanks for replying. > > On Wednesday 16 March 2005 16:46, Kern Sibbald wrote: > > Hello, > > > > Before reporting the informational messages below as bugs, please > > note that they are totally normal. If you turn off the -v option on > > the command line of the SD you will not get those messages. > > I understand this. But I do not understand why those messages do not > appear with 1.36.1. Additionally, the restore is _much_ faster with > 1.36.1, same system, same fileset. With 1.36.2 the restore did not > seem to finish but rather insisted on spewing out "EOF" messages, > although I must say I waited not more than 10 minutes because it did > not take nearly that long with 1.36.1. The above is very interesting information that I was not aware of. > > I was just wondering why there's a difference in that case between > those two bacula versions. Yes, there is a very subtle bug fix that I made to prevent Bacula from thinking the tape was truncated after a restored. Perhaps that "fix" is causing it to read a lot more records than it should, making it *much* slower. > > If I just have to wait longer---that's okay for me, I'll try again. Can you build Bacula with a patch that I can supply you and test that? It would be very interesting to try restoring the same file(s) with what you have now and a patched Bacula. If you can, please open a bug report, with bugs.bacula.org, copy in a few EOF messages, and your paragraph above beginning with "I do not understand ...". It is much easier to resolve these issues via the bugs database than via email. Please attach to the bug report your restore.bsr as restore.bsr.txt. Its location is printed just before you answer yes to the restore yes/mod/no prompt. ... -- Best regards, Kern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
