Jon LaBadie's Mail:
> On Wed, Mar 12, 2008 at 04:00:00PM +0100, Paul Bijnens wrote:
[...]
> > I seem to remember there was indeed a problem on some hosts
> > where rewind flagged success and finished, but the tape drive
> > was actually not ready to accept new requests, resulting in IO errors
> > until the tape was fully rewound.
> > 
> > But I do not remember anymore if or how it can be solved
> > (except by modifying the code and waiting longer after the rewind).
> > 
> 
> I was in that situation with a DDS3, 6 tape, tapechanger from HP.
> I ran amanda's use of mt and mtx through wrappers and inserted
> sleeps for various cmds (notably rewinds for up to 20 or 30 sec.)
> and I put in some repeats for things like status checks that
> failed the first time.

Back in May 2007 myselph wrote:

> I had a similar problem with with a DDS3 tape drive (HP-C1537A) connected
> to my alpha running (at that time) DU 4.0d.  It seemed to me that the
> drive / driver returns immediately after a rewind operation, but a
> following write on the same (kept-open) filedescriptor returns
> unsuccessfully if the rewind did not complete yet.  Amtapetype exactly
> does this.
> 
> The situation was not reproducible in my setup by a sequence of shell
> commands (like ``mt rewind; tar -c ...''), as each shell command is an own
> process and opens its own filedescriptor for accessing the tape.
The problem also existed after my box having been updated to Tru64 5.1B-3.

The attached patch (relative to 2.5.2) fixed the problem for me.

In June Ian Turner contacted me for testing alternative solutions
for the rewind / timeout / IO error problem, but on Tru64 only the
open / close workaround was fully successful.

I don't know, if the workaround has been integrated in more recent
versions of amanda.

Regards

        \franz

amanda-2.5.2-tapetype.patch
Description: amanda-2.5.2-tapetype.patch