On Tuesday 11 January 2005 09:12, Stefan G. Weichinger wrote:
>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.

Given that the tapes she has made aren't going to be terribly usefull 
anyway Stephan, my thoughts run toward doing an amrmtape on those, 
and then relabeling them again once the correct blocksize is set, 
bearing in mind that this *must* be reset everytime a different tape 
is loaded into the drive until all have been re-written with the new 
proper blocksize, and done before the labeling of each tape is done.

Thinking over a 32 byte block, just the label would be 2 blocks!  
Yeah, relabel them as above.  Just don't forget to reset the 
blocksize after each tape has been accepted by the drive, and before 
relabeling each tape.  That should work.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.