Re: AIT2 tape size?
Toralf Lund wrote:
I've been meaning to ask about this for a long time:
Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup?
What tape length are you using? [ ... ]
I've now finally run amtape - after making absolutely sure H/W
compression was off - and it said:
-sh-2.05b$ amtapetype -e 50g -t SDX2-50C-NOHWC -f /dev/tape
Writing 256 Mbyte compresseable data: 44 sec
Writing 256 Mbyte uncompresseable data: 44 sec
Estimated time to write 2 * 51200 Mbyte: 17600 sec = 4 h 53 min
wrote 1540096 32Kb blocks in 94 files in 8139 seconds (short write)
wrote 1531904 32Kb blocks in 187 files in 8236 seconds (short write)
define tapetype SDX2-50C-NOHWC {
comment "just produced by tapetype prog (hardware compression off)"
length 48386 mbytes
filemark 2818 kbytes
speed 6003 kps
}
The size reported is as you can see quite a bit below 50Gb, but close to
5000b, so I guess the capacity is 50 salesman's gigabytes, like
someone suggested. I seem to remember writing closer to 25 *real* Gb on
an AIT-1, though, so it may still look like the capacity is less than
doubled with AIT-2, but I could be wrong...
- Toralf
Re: AIT2 tape size?
[ ... ] (*) 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.) It's the "stinit" program, which is included in the "mt-st" package, that allows this, but as far as I can tell, it's not actually used in the default setup. - Toralf
Re: AIT2 tape size?
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.
Re: AIT2 tape size?
Toralf Lund wrote:
> I've been meaning to ask about this for a long time:
>
> Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup? What
> tape length are you using?
I ran amtapetype on my AIT-2 and;
define tapetype AIT2 {
comment "AIT-2 with 230m tapes"
length 43778 mbytes
filemark 3120 kbytes
speed 5371 kps
}
This has proven pretty accurate.
> Please note that I'm not asking for the tapetype entry from the
> amanda.org archives, as it does not seem quite correct. I mean, the tape
> size is specified as 50Gb, and that's more or less what the "length"
> parameter in entry says, but it seems to me that it isn't actually
> possible to write that much data to these tapes. The maximum seems to be
> closer to 40Gb, actually.
>
> OK, I might run amtapetype, but I'm lazy... And I'm also curious about
> other people's experience with this tapes. For instance, can anyone
> actually write as much as 50Gb?
>
> - Toralf
>
--
Stephen Carville -- polluting the ranks of skeptics since 1995.
---
Government is actually the worst failure of civilized man. There has
never been a really good one, and even those that are most tolerable are
arbitrary, cruel, grasping and unintelligent.
-- H. L. Mencken
Re: AIT2 tape size?
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. It can even be manipulated by dipswitches on the tapedrive itself. 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. I.e. if you have a tape that was written with hardware compression, and you first read some bytes of the tape (as amanda does to verify the label), and subsequently write something to the tape, the tape is written with hardware compression, whatever you switched the drive before. 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. (*) 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). 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. 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. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: AIT2 tape size?
On Thu, 18 Aug 2005 at 3:26pm, Paul Bijnens wrote > Toralf Lund wrote: > > Ah, yes, of course. No, hardware compression is not supposed to be on. > > But I'm not sure it isn't... In fact, now that to mention it, I suspect > > it's on after all. I'll a have a closer look. And I very much doubt that > > the drive will auto-detect compressed data. > > amtapetype will tell you too if hardware compression is on. On Linux (at least), so will 'tapeinfo', which comes with mtx. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: AIT2 tape size?
Paul Bijnens wrote: Toralf Lund wrote: Ah, yes, of course. No, hardware compression is not supposed to be on. But I'm not sure it isn't... In fact, now that to mention it, I suspect it's on after all. I'll a have a closer look. And I very much doubt that the drive will auto-detect compressed data. 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?
Re: AIT2 tape size?
Toralf Lund wrote: Ah, yes, of course. No, hardware compression is not supposed to be on. But I'm not sure it isn't... In fact, now that to mention it, I suspect it's on after all. I'll a have a closer look. And I very much doubt that the drive will auto-detect compressed data. amtapetype will tell you too if hardware compression is on. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: AIT2 tape size?
Mine will consistenly write in the area of 4400kb , the most so far this year on one tape was 47896576kb. - toby bluhm philips medical systems, cleveland ohio [EMAIL PROTECTED] 440-483-5323 [EMAIL PROTECTED] wrote on 08/18/2005 08:01:09 AM: > I've been meaning to ask about this for a long time: > > Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup? What > tape length are you using? > > Please note that I'm not asking for the tapetype entry from the > amanda.org archives, as it does not seem quite correct. I mean, the tape > size is specified as 50Gb, and that's more or less what the "length" > parameter in entry says, but it seems to me that it isn't actually > possible to write that much data to these tapes. The maximum seems to be > closer to 40Gb, actually. > > OK, I might run amtapetype, but I'm lazy... And I'm also curious about > other people's experience with this tapes. For instance, can anyone > actually write as much as 50Gb? > > - Toralf >
Re: AIT2 tape size?
Toralf Lund wrote:
Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup?
What tape length are you using?
This is the tapetype entry we use in our amanda.conf:
# christian found this definition on the internet
# @ http://www.sun.com/bigadmin/features/articles/backups_amanda.html
define tapetype SDX2-50C {
comment "AIT2"
length 5 mbytes
filemark 3120 kbytes
speed 5371 kps
}
Seems to work. Note that we till now don't use the full size of the
tapes. As dump-type, we use the pre-defined comp-root from amanda.conf:
define dumptype comp-root {
comment "Root partitions with compression"
options compress-fast, index
priority low
}
So that we use software compression.
Cheers, Christian
--
This is Linux Land-
In silent nights you can hear the windows machines rebooting
Re: AIT2 tape size?
Alexander Jolk wrote: Toralf Lund wrote: the tape size is specified as 50Gb, and that's more or less what the "length" parameter in entry says, but it seems to me that it isn't actually possible to write that much data to these tapes. The maximum seems to be closer to 40Gb, actually. That sounds like hardware compression of already software-compressed data. Are you sure you are not using both? (Or else, are AITs as intelligent as LTOs in not recompressing already compressed data?) Ah, yes, of course. No, hardware compression is not supposed to be on. But I'm not sure it isn't... In fact, now that to mention it, I suspect it's on after all. I'll a have a closer look. And I very much doubt that the drive will auto-detect compressed data. Thanks. - Toralf
Re: AIT2 tape size?
Toralf Lund wrote: the tape size is specified as 50Gb, and that's more or less what the "length" parameter in entry says, but it seems to me that it isn't actually possible to write that much data to these tapes. The maximum seems to be closer to 40Gb, actually. That sounds like hardware compression of already software-compressed data. Are you sure you are not using both? (Or else, are AITs as intelligent as LTOs in not recompressing already compressed data?) Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
AIT2 tape size?
I've been meaning to ask about this for a long time: Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup? What tape length are you using? Please note that I'm not asking for the tapetype entry from the amanda.org archives, as it does not seem quite correct. I mean, the tape size is specified as 50Gb, and that's more or less what the "length" parameter in entry says, but it seems to me that it isn't actually possible to write that much data to these tapes. The maximum seems to be closer to 40Gb, actually. OK, I might run amtapetype, but I'm lazy... And I'm also curious about other people's experience with this tapes. For instance, can anyone actually write as much as 50Gb? - Toralf
