On Wed March 12 2003 06:46, Sven Rudolph wrote:
>Gene Heskett <gene_heskett AT iolinc DOT net> writes:
>> To get around this, one would assume that amcheck has already
>> been run, and that the correct tape for tonights session is
>> indeed loaded into the drive,
>
>This doesn't work when you have to write to more than one
>tape. Sometimes you do not even know in advance how many tapes
> will be needed.
This is true, and I don't have a good fix for that other than to
treat them all by hand after loading them into the magazine, doing
it each time any untreated tapes have been loaded.
>> a: rewind tape
>> b: dd tape label to scratch file, don't forget the 'bs=32k'
>> c: rewind tape
>> d: turn compression off by whatever method
>> e: dd 10 megs or more worth of /dev/zero to the drive, causing
>> it to flush its buffers. This will cause that compression flag
>> to be reset permanently on this tape. Using bs=32k of course f:
>> rewind tape
>> g: dd the scratch file back to the tape to restore the proper
>> label.
>
>For my DLT drives writing 32k is sufficient.
On thinking this over, it may be true for any useage of the
rewinding device, because the close and rewind would force the
buffer flush. Good point, and a time saver too.
>The taper rewrites the label anyway, so the only additional step
> is to have the taper do the mt call before writing the label
> back.
Also true, but I'll leave that to the folks who walk around in that
code in their sleep. :)
>Two options:
>- do the ioctl internally. This might be machine-specific ...
Is that not something that a good configure.in writer couldn't
ascertain somehow? I mean I've seen configure ask the darndest
questions at times.
>- call external mt. This means taper has to close the tape fd,
> call the external program and the reopen the tape. This is
> against taper's race-avoiding principles.
But doable if the non-rewinding device is used. We're talking about
maybe a 3 second exposure here, maximum, unless the machine is a
certified, can't hunt anymore, dawg.
>But when you handcraft this by any workaround like you proposed,
> there are even more races possible. (Like something migt change
> the tape beetween your amcheck and yout script-erasing.)
Yup, cause amcheck emailed them that the wrong tape(s) are in the
magazine. In a home situation such as mine, thats not a concern as
the missus stays as fur from this thing as she can. She did
successfully do the tape changing while I was out of town for 2
weeks last fall, but it was against her better judgement, and she
told me so. ;-)
>So I see these two options which both have their drawbacks.
Acceptable risks. Yes they do need evaluated, particularly in a
commercial environment, but in the huge majority of the cases I can
envision, it doesn't seem to be a showstopper.
We're sitting here, beating this subject to death, when it really is
something that should be addressed (IMO) at some point by someone
with authority over the code like JRJ. It is a nearly constant
gotcha for the noobie trying to get his system running as
efficiently as his hardware will allow...
It seems to me that a simple ./configure --nocompression argument
could be used to have taper (or whatever by breaking that ioctl out
into a seperate function included by any util that needs it, and
have that function do it as soon as the rewind is complete if that
option was set at compile time. That would make sure its off
before writing the first byte to any rewound tape.
Food for thought anyway.
--
Cheers Sven, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.24% setiathome rank, not too shabby for a WV hillbilly
|
