Hi,

Sorry for the delay in replying (over a week), I got pulled to
another site for a week.

I'm going to combine the results of a few peoples suggestions
into this same email. Thanks for the help thus far.

Things I have done:

1. Created an /etc/stinit.def file so that the block size is set
to "0" and compression is (theoretically) disabled.

2. Run a cleaning tape through the system a good number of
times.

3. Tried different tapes, all with the same response. I haven't
tried a brand new tape, as I don't have one at the moment. I
have tried three seperate tapes that were all working
previously.

4. I used a different tapetype utility (thanks JC) that reported
the size of the tapedrive at 35508 MB, which is about what I
would expect but it also tells me that hardware compression was
on, else it should not have made it past 20GB (note this was
BEFORE I implemented step 1, I will run it again to see what
happens, but it takes > 24 hours to complete !)

5. Output from the command "dd ibs=32k if=/dev/st0" gives:

===============
AMANDA: TAPESTART DATE X TAPE daily01thu


1+0 records in
64+0 records out
===============

so it would appear that it is actually labelling the tape
properly, just not being able to read them.


The end result is that I am still getting the following error,
when I run amcheck:

=============================
amcheck-server: strange amanda header: "AMANDA: T"
 ERROR: /dev/nst0: not an amanda tape
     (expecting tape daily01tue or a new tape)
=============================

any more suggestions ?


Thanks,
Tony.



 --- Paul Bijnens <paul.bijnens AT xplanation DOT com> wrote: 
> Tony wrote:
> 
> 
> > amcheck-server: strange amanda header: "AMANDA: T"
> > ERROR: /dev/nst0: not an amanda tape
> >        (expecting tape daily01tue or a new tape)
> > 
> 
> This seems to me like a blocksize problem. (Not 100% sure,
> because your blocksize seems to be 9 bytes!?!??, very
> uncommon.)
> 
> As long as the read blocksize, the write blocksize and the
> tape blocksize is the same, you won't notice any problem.
> You can configure a tape driver with fixed blocksizes on tape;
> but when doing this, the behavior of different OS'es when
> reading
> or writing such tapes is quiet different (and still not clear
> to me!).
> 
> When reading a tape, it usually works if your read blocksize
> is
> at least as big as the tape blocksize.   When writing a tape,
> different OS'es do different things: split the buffer over
> different
> blocks, or even simply trowing away the excess bytes!
> What happens with the padded bytes in the last block is even
> more
> unclear.
> 
> To avoid all the confusion, I usually use variable blocksize
> on tape
> (indicated by a zero), and let amanda use it's default
> blocksize
> of 32Kbytes on such tapes.
> 
> What is the current blocksize of your tape?  Try:
>    mt -f /dev/st0 status
> 
> And set it to variable blocksize with:
>    mt -f /dev/st0 blocksize 0
> 
> For Linux, you should configure the blocksize (and
> compression) defaults
> for your tapedrives in the file /etc/stinit.def.
> Finding a decent explanation of the contents of that file is
> still
> on my todo list.  Google around for "stinit.def amanda" and it
> will
> show up some interesting pages.
> 
> -- 
> Paul Bijnens

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk