|
Re: AIT2 tape size?
2005-08-19 03:05:04
Paul Bijnens wrote:
Toralf Lund wrote:
Paul Bijnens wrote:
amtapetype will tell you too if hardware compression is on.
OK.
Does amanda have any built-in support for switching it off? I mean,
can any of the changer scripts or whatever do this? Or even amdump
itself?
No. Controlling hardware compression is a very OS and hardware
specific issue.
I thought that there was at least *some* attempt at a standard way of
doing it in the SCSI protocol, although I do know it's done in
completely different ways at the user level of different OSes. That's
one of the main reason we may have got it wrong, actually. The setup was
originally running on an SGI server, and there it was really easy to get
it right, since you could choose compression mode via the device
selection - i.e. /dev had separate files files for compressed and
non-compressed access to the unit. But now it's all moved to Linux...
In any case, the tape changer scripts can of course be easily modified,
but it would be nice if the "standard" ones at least had some kind of
mechanism for hooking in "mt" commands or whatever that might do
tapedrive config like this.
It can even be manipulated by dipswitches on the tapedrive itself.
We haven't actually been able to find any of those on this particular
unit (i.e. the tape library), or a compression configuration item in the
built-in web software. But maybe there are switches on the actual drive.
It can even be more complicated: when reading a tape, the drive
adjusts itself automatically to the correct setting.
On some(*) linux versions this results in automatically writing
with whatever setting the tape was previously written. [ ... ]
To get out of this situation, you have to
insert the tape, disable hardware compression, and write some data
to the tape WITHOUT reading something first.
URGH. I didn't know it was that bad ;-(
(*) I used to say "on all linux versions", but it seems there
are different implementations in different versions.
Some systems can control the tapesettings with the file
/etc/stinit.def (see "man stinit" if that exists).
Yes. I think maybe you can do something like that on this one (Red Hat.)
There is also a method to use different device names (**), just
as in Solaris, where the letters c, h, m, l are indications
of compression and density to use when writing.
Right. That's what SGI IRIX does, too.
This avoids
the above problems, because when you open() a drive for writing,
the device name (minor device number actually) contains the settings
for the drive implicitly.
The whole problem is still not completely clear to me.
And the lack of documentation on the st-driver in Linux does not help
either. I mean: any pointers are welcome.
(**) at least the comments in the kernel source code in
drivers/scsi/st.c seem to imply this, but I cannot find any other
decent documentation of this.
|
|
|
