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

Reply via email to