Re: problem labelling tapes
2003-10-16 04:17:27
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
|
|
|