Amanda-Users

Re: VXA-V23 taoe difficulties

2005-12-14 06:28:27
Subject: Re: VXA-V23 taoe difficulties
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: "Hommersom, Gerrit (G)" <GHOMMERSOM AT dow DOT com>
Date: Wed, 14 Dec 2005 12:22:30 +0100
Hommersom, Gerrit (G) wrote:
I am using Amanda for year as primary backup tool for my Linux/Unix pool.

Some months I introduced an Exabyte VXA drive and VXA-V23 (80GB
uncompressed) tapes to cope with the ever expanding storage.
I backup 25 DLE's of varying size 18 MB to 55 GB. Amanda nor the
hardware compress the data.
TapeType definition sets the Tapesize to 75 GB to add some slack in
the system.
Backup program is gtar.

Recently I get the following error when the large DLE's are backup up

*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next tape Amanda expects to use is:

The mail message indicates that only 65 GB has actually been written at the 
time the tape ran out.
 taper: tape xxxxxx kb 65110688 fm 25 writing file: No space left on device

The tape really bumped into -- what it diagnosed as -- end of tape
at this point.

The problem is that "bumping into end of tape" is implemented as a
"hard write error" on the same spot.

For this you have to understand that most tapedrives (disclaimer: I do not know a VXA drive, this could be different here) have a read head
that verifies what they write.  During writing, error correcting and
error detecting bits are added, and many of the write errors can be
corrected by those additional error correcting bits.  When writing
a block, and the read head diagnoses this as a bad block, the tape does
not rewind, but the firmware rewrites the same block again, in the hope
it does write correctly this time. If after a certain number of these "soft" errors, the error persists, this becomes a "hard" error.

Bumping into end of tape is the same: the tape drive tries to write
a block, but it does not succeed, resulting in a "hard error".

The result of all this guessing is that most drives report a "hard
write error" as "end of tape".

Only in some circumstances, a drive can really know that it did not
bump into the "real" end of tape, but had a real I/O error.

Cleaning the tape drive helps sometimes.


Some incremental backups (9 in total) are very small 60 KB to 5 MB. Can this be the cause of the gross miscalculation of the tapelength?? What is the minimum tape length for a DLE backup ??

I guess this has nothing to do with it.


--
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************



<Prev in Thread] Current Thread [Next in Thread>