Thank you Brian.  Unfortunately the drive itself is IDE.

I changed the bacula-sd Device resource:

    TWO EOF = yes                   # default = No

It completes test with success now but fill (m) fails now:

22:16:37 Flush block, write EOF
Wrote block=275000, file,blk=18,11499 VolBytes=17,740,735,488 rate=5.494 MB/s
Wrote block=280000, file,blk=19,999 VolBytes=18,063,295,488 rate=5.495 MB/s
Wrote block=285000, file,blk=19,5999 VolBytes=18,385,855,488 rate=5.499 MB/s
07-Jan 22:18 btape JobId 0: Error: block.c:573 Write error at 19:7106 on device 
"Exabyte_VXA-2" (/dev/nst0). ERR=Input/output error.
07-Jan 22:18 btape JobId 0: Error: dev.c:1740 ioctl MTWEOF error on 
"Exabyte_VXA-2" (/dev/nst0). ERR=Input/output error.
07-Jan 22:19 btape JobId 0: Fatal error: Re-read of last block: block numbers 
differ by more than one.
Probable tape misconfiguration and data loss. Read block=279000 Want 
block=286106.
btape: btape.c:2701 Last block at: 19:7105 this_dev_block_num=7106
btape: btape.c:2736 End of tape 18:0. Volume Bytes=18,457,270,272. Write rate = 
5.423 MB/s
07-Jan 22:19 btape JobId 0: End of medium on Volume "TestVolume1" 
Bytes=18,457,270,272 Blocks=286,106 at 07-Jan-2001 22:19.
07-Jan 22:19 btape JobId 0: Fatal error: Job 0 canceled.
btape: btape.c:2743 Cannot fixup device error. dev.c:1740 ioctl MTWEOF error on 
"Exabyte_VXA-2" (/dev/nst0). ERR=Input/output error.

btape: btape.c:2277 Flush block failed.
btape: btape.c:2316 Not OK
btape: btape.c:2380 Wrote state file last_block_num1=7105 last_block_num2=0
btape: btape.c:2408 22:19:34: Error during test.

The complete configuration file bacula-sd.conf:

http://kosmosisland.com/9e0d97c23a8836b37747f65b9fc8955f/bacula-sd.conf

Regards,
David Koski
da...@kosmosisland.com

On Tuesday 09 March 2010, Brian Debelius wrote:
> 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
> > da...@kosmosisland.com
> >
> > 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
> >>> da...@kosmosis.and.com
> >>>
> >>> 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
> >>>>> da...@kosmosisland.com
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> -- -- -- --- 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
> >>>>> Bacula-devel@lists.sourceforge.net
> >>>>> 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
> >>> Bacula-devel@lists.sourceforge.net
> >>> 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
> > Bacula-devel@lists.sourceforge.net
> > 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
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to