On Saturday 24 May 2003 02:15, Mathias Körber wrote:
>Jon LaBadie <jon@j...> wrote:
>>> Change that to a -c true/false, and it would be a winner. The
>>> problem with that is that the various drives take various
>>> commands to effect that, so it might be required to have a
>>> preset file, built by the user, that contains the required
>>> command syntax to do that to *his* drive. It would also require
>>> a bit of must read documentation, and with some users, thats
>>> always going to be a problem due to a general lack of RTFM. In
>>> particular the noobie is going to be asking a lot of why can't
>>> amlabel just work, when in fact it cannot find the syntax file
>>> the user hasn't generated.
>
>Maybe Amanda should generally have a typedrive specification which
>contains such information (similar to dumptypes, interfaces etc).
>
>> Kinda tough to do on a system such as mine which doesn't have
>> commands or calls to change compression settings. It is done
>> on the "open" call to the tape drive (and driver) by selecting
>> a device name. Like you call nst0 or st0 to select no/rewind.
>> How do you change that behavior after opening the drive?
AFAIK, you cannot, mt's access is blocked by the open path.
>what system is that? This to me is the ideal way as you can simply
>select the device with the behaviour yo want.
Thats from Jon LaBadie, and his system is running solaris, where the
drives compression state is set by the choice of /dev/device used.
>> Of course that is also the reason I don't suffer from the change
>> upon read problem you have.
Actually Jon, its not the read that does it according to my line of
reasoning.
Warning: The ancient troubleshooter at work here folks. Heres my
reasoning.
Where this override function seems to take place is in the tape
recognition phase thats done when the tape is inserted. The
apparent permanency comes from changing it with mt, but then not
forcing a buffer flush before the tape is ejected, so the tape
itself never gets updated.
Its my belief that causeing the flushing of the buffer first
rewrites this hidden header to reflect the instant state. If thats
not done, then the tape will be back to compressed the next time
its inserted. So theoreticly reading the label block out with dd
and the rewinding device, changeing it with mt, and then putting
the label block back on the tape with dd and the rewinding device
which forces the close and the buffer flush, should do what needs
to be done. Its also going to be somewhat faster than writing 20
megs worth of /dev/zero to force the flush if one has a large
quantity of tapes to so process. Been there, done that using my
original method, boreing :(
>I wish the Linux SCSI tape river did that (or maybe it does and I
>have not found it yet).
Its possible that the proper entries in stinit might be able to do
that, but the manpage is, shall we say, a bit murky to me. Thats
not saying its poorly written, because its not, but its a bit
concise for my taste since I tend to run toward too verbose myself
:)
>
>>> >> amtapetype from 2.4.4 does a write without a read (and will
>>> >> detect hw compression if still on :-) ).
>>>
>>> What does this portion of its report look like?
>
>It prints two lines:
>
>tapetype.c: fprintf(stderr, "\rWriting %d Mbyte compresseable
> data: %d sec\n",
>tapetype.c: fprintf(stderr, "\rWriting %d Mbyte uncompresseable
> data: %d sec\n",
>
>If the seconds are noticeably different, the tape compresses
> data..
>
>> An error message and exit. No report.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
