From: JML <jm...@le...> - 2004-02-20 19:11:42
|
sorry, my mistake- a default block size was still set. It might be clearer, however, if that tip moved from section 17.7 to 17.6 in the docs. By the way, should I be concerned that bacula wrote to tape without reporting errors in spite of the incorrect block size? In other words, any chance that it would write a tape that was later unreadable, even if the setting were corrected after the fact? I'm thinking of the sysadmin who forgets to script the mt commands for startup, or the newbie who never tests restores until they're needed. :) regards, Jason On Thu, 19 Feb 2004, Kern Sibbald wrote: > Hello, > > Before running the btape "test", run the mt command recommended in the > manual that sets your SCSI driver parameters. > > Then please send me the full output from the latest btape 1.33.3-16Feb04 > "test" command, and I'll look at it. Also please send me your > bacula-sd.conf (I know you sent it before, but it is buried somewhere > long ago ...). > > Best regards, Kern > > On Wed, 2004-02-18 at 22:19, JML wrote: > > Hi Kern, > > > > a quick update since my previous post below- the new btape in 1.33.3 > > reports the same problem with our DDS-4. Any thoughts on what I should try > > next? > > > > thanks, > > > > Jason > > > > > > On Fri, 13 Feb 2004, JML wrote: > > > > > Yes, the problem seems odd for so mainstream a drive as this. I followed > > > your suggestions on tape cleaning and alternate tapes, but they check out > > > okay. I can even write and read tar archives from the device with no > > > problem. > > > > > > In case they offer any clues, I've attached the results from tapeinfo, mt > > > status, and the CVS version btape, which does catch an error now BTW. It > > > also seems odd that tapeinfo reports "Medium Type: Not Loaded" when it is > > > loaded. > > > > > > thanks, > > > > > > Jason > > > > > > > > > On Fri, 13 Feb 2004, Kern Sibbald wrote: > > > > > > > Hello, > > > > > > > > Fast block rejection is still turned off in 1.33. In fact, it should > > > > cause problems only if using multiple concurrent jobs, so I doubt it is > > > > the problem here. With a Sony DDS-4 you should be having no problems. > > > > I'd recommend that you remove the: > > > > > > > > Fast Forward Space File = no > > > > Backward Space Record = No > > > > > > > > as they just cripple your excellent drive. It may be that you have a > > > > bad tape, or a dirty drive, so I would recommend you run a cleaning tape > > > > at least once, then as I suggested in a previous email, download the > > > > latest CVS code and rebuild btape. It now has a tape block read back > > > > test as well as a positioning test, so maybe something will show up. > > > > > > > > Best regards, Kern > > > > > > > > > > > > On Fri, 2004-02-13 at 05:35, JML wrote: > > > > > Hello again, > > > > > > > > > > I have a separate issue with restoring from a DDS-4 changer (specifically > > > > > a Sony TSL-S11000). System is RedHat 9. Changer ops and backup work fine, > > > > > then I get the following during a restore job: > > > > > > > > > > nail-sd: Ready to read from volume "foo-06" on device /dev/nst0. > > > > > nail-sd: Forward spacing to file:block 0:1. > > > > > nail-sd: RestoreFiles.2004-02-12_16.36.23 Error: block.c:248 Expected > > > > > block-id BB01 or BB02, got . Buffer discarded. > > > > > nail-sd: RestoreFiles.2004-02-12_16.36.23 Error: block.c:248 Expected > > > > > block-id BB01 or BB02, got . Buffer discarded. > > > > > nail-sd: RestoreFiles.2004-02-12_16.36.23 Error: Read error on Record > > > > > Header /dev/nst0: Success > > > > > nail-fd: RestoreFiles.2004-02-12_16.36.23 Error: bnet.c:374 Write error > > > > > sending to Storage daemon:nail:9103: ERR=Broken pipe > > > > > nail-dir: RestoreFiles.2004-02-12_16.36.23 Error: Bacula 1.33 (30Jan04): > > > > > 12-Feb-2004 16:38 > > > > > JobId: 35 > > > > > Job: RestoreFiles.2004-02-12_16.36.23 > > > > > Client: nail-fd > > > > > Start time: 12-Feb-2004 16:36 > > > > > End time: 12-Feb-2004 16:38 > > > > > Files Restored: 0 > > > > > Bytes Restored: 0 > > > > > Rate: 0.0 KB/s > > > > > FD Errors: 1 > > > > > FD termination status: Error > > > > > SD termination status: Error > > > > > Termination: *** Restore Error *** > > > > > > > > > > Seems to make no difference whether I "mark *" or only restore a subset of > > > > > the job. I also followed the instructions pertaining to mt stoptions. > > > > > > > > > > btape's test gives a clean bill of health on this drive, though after > > > > > advising that I set the last two options in my Device declaration below: > > > > > > > > > > Device { > > > > > Name = DDS-4 # > > > > > Media Type = DDS-4 > > > > > Archive Device = /dev/nst0 > > > > > Autochanger = Yes > > > > > Changer Command = "/usr/local/bacula/etc/mtx-changer %c %o %S %a" > > > > > Changer Device = /dev/sg1 > > > > > LabelMedia = No > > > > > AutomaticMount = yes; # when device opened, read it > > > > > AlwaysOpen = yes; > > > > > Fast Forward Space File = no > > > > > Backward Space Record = No > > > > > } > > > > > > > > > > > > > > > > > > > > All of this sounds similar to a thread from last week when the advice was > > > > > to upgrade to 1.32f-4, which had fast block rejection disabled. Is this > > > > > disabled already in the 1.33 beta, or is there an easy way to do so? > > > > > > > > > > best, > > > > > > > > > > Jason > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > > > > > Build and deploy apps & Web services for Linux with > > > > > a free DVD software kit from IBM. Click Now! > > > > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > > > > > _______________________________________________ > > > > > Bacula-users mailing list > > > > > Bac...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > > > > > > > > > > > > > > > > > |