Thank you Kern. I'll dig into it some more. For the list, it is Linux and firewire with Bacula 5.0.0-5 Debian platform and package.
Regards, David Koski [email protected] On Tuesday 09 March 2010, Kern Sibbald wrote: > Hello, > > This means that your tape drive parameters are not properly set. You have > never specified what OS and version you are using. This is not the normal > kinds of problems we see on Linux systems. > > Unfortunately, as I previously mentioned, you will need to do this yourself > or get professional help. I no longer have enough time to deal with all my > emails, much less provide support -- unless it is through Bacula Systems. > > Best regards, > > Kern > > On Monday 08 March 2010 22:37:03 David Koski wrote: > > Hello Kern, > > > > I executed the test command and got an error here: > > > > Doing Bacula scan of blocks: > > 1 block of 64448 bytes in file 1 > > End of File mark. > > 2 blocks of 64448 bytes in file 2 > > End of File mark. > > 4 blocks of 64448 bytes in file 3 > > End of File mark. > > Total files=3, blocks=7, bytes = 451,136 > > End scanning the tape. > > We should be in file 4. I am at file 3. This is NOT correct!!!! > > > > The above Bacula scan should have output identical to what follows. > > Please double check it ... > > === Sample correct output === > > 1 block of 64448 bytes in file 1 > > End of File mark. > > 2 blocks of 64448 bytes in file 2 > > End of File mark. > > 3 blocks of 64448 bytes in file 3 > > End of File mark. > > 1 block of 64448 bytes in file 4 > > End of File mark. > > Total files=4, blocks=7, bytes = 451,136 > > === End sample correct output === > > > > If the above scan output is not identical to the > > sample output, you MUST correct the problem > > or Bacula will not be able to write multiple Jobs to > > the tape. > > > > > > Does this change anything? > > > > Thank You, > > David Koski > > [email protected] > > > > On Monday 08 March 2010, Kern Sibbald wrote: > > > Hello, > > > > > > Well, you are working with one of the most complicated parts of doing > > > backup -- being able to write correctly to a tape drive. > > > Unfortunately, there is no standard tape drive nor any standard driver, > > > and Exabyte is one that is definitely different from what I have read. > > > > > > From the output below, I suspect that the drive (or driver) is not > > > sending back the logical end of tape signal (-1) as it should be and so > > > you have written off then end of the physical tape (or written right to > > > it). If this is the case, and it takes a really careful look at what > > > is happening at the end of the tape to know (all of which is > > > complicated by the fact that tapes take a long time to write to the end > > > of the tape). > > > > > > I suggest several things: > > > 1. Run through all the 9 (I think) tests in Tape testing and make sure > > > *everything* works for all the test prior to the "fill" command. > > > 2. Decide if you want to work on the problem yourself, in which case, > > > you will probably need to manually simulate writing to the end of the > > > tape to see the exact status that is returned and *exactly* what > > > happens when it attempts to write an EOF then backup over it. > > > 3. If you want someone else to work on it, unfortunately, I don't know > > > anyone but me who knows how to do this. If you want to go that route, > > > it would be with a contract with Bacula Systems. > > > > > > 4. An alternative that would work quite well would to be to fix a > > > maximum tape size in the SD. If you set the size to something that you > > > are sure is smaller than the shortest tape, but sufficiently close to > > > the end of the tape, you will be OK. Since it will be Bacula that > > > decides to end the tape, it will not need to backup and read the last > > > record, so the problem will go away. The only downside is that you > > > will not be filling the tapes 100%. > > > > > > Best regards, > > > > > > Kern > > > > > > On Monday 08 March 2010 02:52:39 David Koski wrote: > > > > I have tried many iterations of btape to get a simplified single tape > > > > test to work with a VXA-2 Exabyte drive in a Storageloader. This > > > > issue has been submitted to the user list without resolution. I have > > > > tried many variations of a Device resource witout success. The > > > > attempts always result in "Backspace file at EOT failed". The tail > > > > of the output: > > > > > > > > > > > > Wrote block=265000, file,blk=18,1499 VolBytes=17,095,615,488 > > > > rate=5.502 MB/s Wrote block=270000, file,blk=18,6499 > > > > VolBytes=17,418,175,488 rate=5.505 MB/s 14:58:25 Flush block, write > > > > EOF > > > > Wrote block=275000, file,blk=18,11499 VolBytes=17,740,735,488 > > > > rate=5.509 MB/s Wrote block=280000, file,blk=19,999 > > > > VolBytes=18,063,295,488 rate=5.510 MB/s Wrote block=285000, > > > > file,blk=19,5999 > > > > VolBytes=18,385,855,488 rate=5.514 MB/s 05-Jan 15:00 btape JobId 0: > > > > Error: block.c:573 Write error at 19:7055 on device "Exabyte_VXA-2" > > > > (/dev/nst0). ERR=Input/output error. 05-Jan 15:00 btape JobId 0: > > > > Error: Backspace file at EOT failed. ERR=Input/output error btape: > > > > btape.c:2701 Last block at: 19:7054 this_dev_block_num=7055 btape: > > > > btape.c:2736 End of tape 19:0. Volume Bytes=18,453,980,160. Write > > > > rate = 5.511 MB/s btape: btape.c:2311 Wrote 1000 blocks on second > > > > tape. Done. > > > > Done writing 0 records ... > > > > btape: btape.c:2380 Wrote state file last_block_num1=7054 > > > > last_block_num2=0 btape: btape.c:2395 > > > > > > > > 15:00:37 Done filling tape at 19:0. Now beginning re-read of tape ... > > > > btape: btape.c:2476 Enter do_unfill > > > > 05-Jan 15:02 btape JobId 0: Ready to read from volume "TestVolume1" > > > > on device "Exabyte_VXA-2" (/dev/nst0). Rewinding. > > > > Reading the first 10000 records from 0:0. > > > > 10000 records read now at 1:5084 > > > > Reposition from 1:5084 to 19:7054 > > > > Reading block 7054. > > > > > > > > The last block on the tape matches. Test succeeded. > > > > > > > > btape: btape.c:2403 do_unfill failed. > > > > > > > > > > > > > > > > My current Device resource is: > > > > > > > > > > > > > > > > Device { > > > > Name = "Exabyte_VXA-2" > > > > # btape cap command: > > > > #EOF BSR BSF FSR FSF !FASTFSF !BSFATEOM !EOM REM !RACCESS > > > > !AUTOMOUNT !LABEL !ANONVOLS ALWAYSOPEN MTIOCGET Media Type = "VXA-2" > > > > Archive Device = /dev/nst0 > > > > Device Type = Tape > > > > Autochanger = yes # if yes, must specify Autochanger > > > > resource Alert Command = "/bin/sh -c '/usr/sbin/tapeinfo -f %c | grep > > > > TapeAlert > > > > > > > > | cat'" # cat returns 0 to prevent error return code from grep > > > > | Maximum > > > > > > > > Changer Wait = 30 minutes > > > > Maximum Rewind Wait = 20 minutes > > > > Maximum Open Wait = 25 minutes > > > > RemovableMedia = yes > > > > AlwaysOpen = yes # default = yes > > > > Random Access = no # no for tapes > > > > Hardware End of Medium = no # default = yes?? > > > > BSF at EOM = yes # docs says default is No but > > > > errors are produced: "Error: Backspace file at EOT failed" > > > > # BSF at EOM = no # docs says default is No but > > > > errors are > > > > > > produced: "Error: Backspace file at EOT failed" > > > > > > > # TWO EOF = yes # default = No > > > > TWO EOF = no # default = No > > > > Forward Space Record = yes # default = yes > > > > Forward Space File = yes # default = yes > > > > Backward Space Record = yes # default = yes > > > > # Backward Space Record = no # default = yes > > > > Backward Space File = yes # default = yes > > > > # Backward Space File = no # default = yes > > > > Fast Forward Space File = no # default = yes > > > > Use MTIOCGET = yes # default = yes > > > > Offline On Unmount = no # default = no > > > > > > > > #AutomaticMount = yes > > > > Auto Select = yes # default = yes > > > > } > > > > > > > > > > > > > > > > The tape drive itself has been swapped out without any change in > > > > results. > > > > > > > > If anyone can shed some light on this it would be much appreciated. > > > > > > > > Best Regards, > > > > David Koski > > > > [email protected] > > > > > > > > --------------------------------------------------------------------- > > > >-- -- -- --- Download Intel® Parallel Studio Eval > > > > Try the new software tools for yourself. Speed compiling, find bugs > > > > proactively, and fine-tune applications for parallel performance. > > > > See why Intel Parallel Studio got high marks during beta. > > > > http://p.sf.net/sfu/intel-sw-dev > > > > _______________________________________________ > > > > Bacula-devel mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > ------------------------------------------------------------------------- > >-- --- Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Bacula-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
