On Wed March 12 2003 06:46, Sven Rudolph wrote: >Gene Heskett <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.24% setiathome rank, not too shabby for a WV hillbilly