Amanda-Users

Re: Antwort: Re: Incredible slow write / Converting tapes

2005-01-11 09:19:04
Subject: Re: Antwort: Re: Incredible slow write / Converting tapes
From: "Stefan G. Weichinger" <monitor AT oops.co DOT at>
To: amanda-users AT amanda DOT org
Date: Tue, 11 Jan 2005 15:12:33 +0100
Hi, Sandra,

on Dienstag, 11. Jänner 2005 at 14:50 you wrote to amanda-users

(in english, obwohl wir beide Deutsch schreiben könnten, aber dann
versteht hier keiner was ;-) ):

SKsdd> Hi Stefan,

SKsdd> errrm, stupid and confused as I was I actually changed
SKsdd> it to 32 bytes (!), but now I corrected it, setting a value of
SKsdd> 32768.

SKsdd> Sorry for messing this up. I now started a new try with
SKsdd> this setting. My fault, that I didn´t made a written notice
SKsdd> when I changed the blocksize on the old machine.
SKsdd> Now I hope, it will run as good as it used to before I changed the 
hardware.

The kernel-messages might have resulted from this setting, let's see.
I assume that you now have documented this setting properly ...

SKsdd> Resulting from the several tries, I now have several
SKsdd> tapes labeled with various blocksizes. How can I convert them
SKsdd> back to the correct one. I assume amlabel won´t do it, cause
SKsdd> when I tried, it is not able to read the tape header.

There has been a thread lately in which Gene Heskett described how to
do that. I paste the relevant part in here:

> You would be useing the setblk and defblksize, or the equ in your copy.
> From the cli:
#>>mt -f device setblk 32768
#>>mt -f device defblksize 32768
> 
> Then you can use a
#>>dd if=/path/to/device of=scratch count=1
> This will read the tapes label out to a tmp file you'll need later
#>>mt -f device rewind
> Then issue the above pair of commands
#>>dd if=scratch of=path/to/device bs=32768 xx=xxxxxxx
> Where the xx=xxxxxx stuff is replaced by whatever command
> dd uses to make it pad a short input file on out to the blocksize
> I'd have typed it here but I've forgotten it, check the manpage
> for that detail.
> 
> Now feed the drive enough data to make it flush the buffers making
> it refresh the expected bloccksize in the hidden header, so figure 
> out how  many of those 32768 chunks will cause the drives 
> advertized buffer to overflow, and use
#>>dd of=/path/to/device if=dev/zero bs=32768 count #howmany

The thread is named "amrestore problem, headers ok but no data" and is
rather huge right now ...

SKsdd> Again sorry for my confusing posts, but I am working on
SKsdd> this quite a few days and the more I try the more confused I
SKsdd> get.

We all know this sort of days ... no problem.

-- 
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor AT oops.co DOT at