Maybe its a firewire problem. Is there any way to test it with SCSI ? On 3/9/2010 11:05 AM, David Koski wrote: > 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 >
------------------------------------------------------------------------------ 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
