Thanks very much for the clear explanation of the potential other causes but
tape-error.
Though I will run a cleaning tape, I have a suspicion that this is not the
case. Tapes themselves are also quite new: 6-7th cycle.
The 'end-of-tape' error occurred on 5 different tapes on 5 consecutive days
for one DLE until I force-bumped all due DLE's except the one failing all
the time.
This one was followed by 2 failures on the next large DLE. I have forced
this DLE and force-bumped all other big DLE's and await tomorrow.
That was the motivation for the minimum tape length of a backed-up DLE.
Kind regards
======================================================
Gerrit Hommersom Dow Benelux BV
tel: -31-115-674102 E&PS/439 Bldg
fax: -31-115-673315 PO Box 48
E-mail: ghommersom AT dow DOT com 4530 AA Terneuzen
-----Original Message-----
From: Paul Bijnens [mailto:paul.bijnens AT xplanation DOT com]
Sent: Wednesday, December 14, 2005 12:23 PM
To: Hommersom, Gerrit (G)
Cc: 'amanda-users AT amanda DOT org'
Subject: Re: VXA-V23 taoe difficulties
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 *
***********************************************************************
|
