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: [EMAIL PROTECTED] 4530 AA Terneuzen -----Original Message----- From: Paul Bijnens [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 12:23 PM To: Hommersom, Gerrit (G) Cc: 'amanda-users@amanda.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: [EMAIL PROTECTED] *********************************************************************** * 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 * ***********************************************************************