I've followed with great interest the discussion on this topic as it
pertains to my backup system

The problems with premature end-of-tape failures persist with big DLE's.
(order 30-35 GB). The problem gets more severe from 1 failure per cycle to
daily failures currently. No dumps are left on the holding disk.

Closer inspection of the Exabyte FAQ learned that this may occur if the
datarate to the drive is too low. The drive waits for input while writing
'gap tracks' that uses physical space.

I re-examined the amanda logs and saw that for large DLE's the datarate for
the dumper and taper are the same and in the order of 3300 KB/s. VXA2 units
write at 6000 KB/s
The main raid-5 taperack is an external SCSI2 unit. The tape is external
SCSI2 too. The holding disk is 39 GB on an internal SCSI2 disk.

My questions:
will amanda use the holding disk for DLE's from on local disk to another
i.e. will DLE's from the external filsystem use the holding disk before
taping.
I accidentally defined a holdingdisk chunksize of 10 GB on a standard (32
bit) linux system. What would be the effect: direct write to tape ??
will the network bandwith parameters affect backup speed of local disks??
What factors may affect the datarate to the tape unit ??

Thanks
Gerrit Hommersom 

-----Original Message-----
From: owner-amanda-users AT amanda DOT org [mailto:owner-amanda-users AT amanda 
DOT org]
On Behalf Of Peter Mueller
Sent: Monday, December 19, 2005 9:34 AM
To: amanda-users AT amanda DOT org
Subject: Re: VXA-V23 taoe difficulties


Hello!



>>> I saw that when it failed and ripped the tape in two on one drive
>>> back in jurrasic times.
>>>
>> So who's throwing away the information ?
>> The tape drive not sensing these holes ?
>> The low level driver not recognising or not asking for the info ? The 
>> general linux/unix tape system not recognising or asking for the info 
>> ?
>
>
> I have the same question.  But no answer.
> I can only assure that my previous AIT-1 tapes only reported 4 times 
> in it's life time (it's dead now) an IO-error, while several other 
> times, it claimed "No space on device", not even near the end, while 
> rewriting the same tape a few days later could put much more data on 
> it.
>
> That tapedrive was connected to Linux but previously to a Solaris 
> machine, and both had the same view of IO-error versus 'No space on
> device.'   I even made a graph of it with gnuplot:


I had similar experiences with several flavours of *ix*,
Linux, Ultrix, OSF1/DigitalUnix/..., HP-UX, ... only to name a few.

It seems to be a conceptual thing of the tape interface to NOT differnciate
between EOT and Read/Write errors - or is it a log lasting bug carried from
one implementation to the other ...

I think to remember that VAX/VMS was much more clever in handling tapes ...
not only the old ANSI beasts, but also the "modern" streaming 
ones.

You could even boot a mini-System from there !
(Not that I would want to do this now, it took ages ... )


Bye, Peter
WOTLmade