SCSI Tape compression
Hi, I'm having troubles compressing a DDS-4 tape. I have an HP C5683A drive, and when I do 'mt -f /dev/nst0 status' (or mtst) I get: twist:/opt/ltt # mtst -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x8c (EXB-8505 compressed). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN The problem is that it's not using compression, although it's turned on. My questions are: - Is EXB-8505 the right compression mode? I read you could change it to DDS-4, but what's the compression code for DDS-4? - Do I need a hardware specific driver for the SCSI controller for the O.S. to recognize the tape in the proper way? - Something I'm missing? Thanks in advance, Sebastian -- Sebastian Jeremias Ingenieria LIGHTECH +54 11 4311.9888 http://www.lightech.biz
On Tuesday 09 August 2005 12:31 pm, Sebastian Jeremias wrote:
Hi, I'm having troubles compressing a DDS-4 tape. I have an HP C5683A drive, and when I do 'mt -f /dev/nst0 status' (or mtst) I get:
twist:/opt/ltt # mtst -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x8c (EXB-8505 compressed). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN
The problem is that it's not using compression, although it's turned on. My questions are: - Is EXB-8505 the right compression mode? I read you could change it to DDS-4, but what's the compression code for DDS-4? - Do I need a hardware specific driver for the SCSI controller for the O.S. to recognize the tape in the proper way? - Something I'm missing?
All of the DAT drives I've ever used did the compression without being told. Are you sure that isn't the case here? What makes you think it isn't using compression? BTW, figure on getting only 1.6 times the data (or less) on the tape when using compression compared to the 2.0 they tell you that you will get.
Bruce Marshall wrote:
All of the DAT drives I've ever used did the compression without being told. Are you sure that isn't the case here?
What makes you think it isn't using compression?
BTW, figure on getting only 1.6 times the data (or less) on the tape when using compression compared to the 2.0 they tell you that you will get.
I'm backing up two partitions. One is 9GB and the other is 11GB. That's MUCH less than 40 :) What's strange is that even software compression wouldn't make it (either bzlib or zlib, level 5). But I'll try that again... it sounds almost weird. Most of the files are plain text. What's the density level I should pass to the dump program to reach DDS-4 density? Thanks a lot
On Tuesday 09 August 2005 01:52 pm, Sebastian Jeremias wrote:
Bruce Marshall wrote:
All of the DAT drives I've ever used did the compression without being told. Are you sure that isn't the case here?
What makes you think it isn't using compression?
BTW, figure on getting only 1.6 times the data (or less) on the tape when using compression compared to the 2.0 they tell you that you will get.
I'm backing up two partitions. One is 9GB and the other is 11GB. That's MUCH less than 40 :)
And the tape runs out??
What's strange is that even software compression wouldn't make it (either bzlib or zlib, level 5).
What does "wouldn't make it" mean?
But I'll try that again... it sounds almost weird. Most of the files are plain text.
What's the density level I should pass to the dump program to reach DDS-4 density?
In my opinion, nothing.
I'm backing up two partitions. One is 9GB and the other is 11GB. That's MUCH less than 40 :)
And the tape runs out??
Yes, it runs out of space with 21GB of data to backup.
What's strange is that even software compression wouldn't make it (either bzlib or zlib, level 5).
What does "wouldn't make it" mean?
It means the tape runs out of space even using level 5 bzlib software compression.
What's the density level I should pass to the dump program to reach DDS-4 density?
In my opinion, nothing.
That's also my opinion, but not the DAT's one... I read the DAT's documentation looking for jumper settings, but found nothing. Could the density/compression level be jumpered? If so, can I override that jumper settings?
On Tue, 2005-08-09 at 14:52 -0300, Sebastian Jeremias wrote:
Bruce Marshall wrote:
All of the DAT drives I've ever used did the compression without being told. Are you sure that isn't the case here?
What makes you think it isn't using compression?
BTW, figure on getting only 1.6 times the data (or less) on the tape when using compression compared to the 2.0 they tell you that you will get.
I'm backing up two partitions. One is 9GB and the other is 11GB. That's MUCH less than 40 :) What's strange is that even software compression wouldn't make it (either bzlib or zlib, level 5). But I'll try that again... it sounds almost weird. Most of the files are plain text.
What's the density level I should pass to the dump program to reach DDS-4 density?
Thanks a lot
I never changed the density on a tape drive but try man mt, it has more info regarding setting density. I'm guessing that the density has something to do with tape capacity. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken Schneider wrote:
I never changed the density on a tape drive but try man mt, it has more info regarding setting density.
I already tryied nearly all mt options without results... I also installed mtst, that's an "enhanced" (?) version of mt, but I got nothing relevant regarding compression.
I'm guessing that the density has something to do with tape capacity.
Me too... that's why I need to know DDS-4 density code to pass to mt, or in bpi, to pass to dump... Thanks, Sebastian
On 8/10/05, Sebastian Jeremias <ljeremias@lightech.com.ar> wrote:
Ken Schneider wrote:
I never changed the density on a tape drive but try man mt, it has more info regarding setting density.
I already tryied nearly all mt options without results... I also installed mtst, that's an "enhanced" (?) version of mt, but I got nothing relevant regarding compression.
I'm guessing that the density has something to do with tape capacity.
Me too... that's why I need to know DDS-4 density code to pass to mt, or in bpi, to pass to dump...
Thanks, Sebastian
Have you looked into stinit? You can set compression in the /etc/stinit.def file. I have not experimented with modifying compression via stinit, but that is another thing you can try. FYI: IIRC the package for this is on the DVD, not the CDs. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
Greg Freemyer wrote:
Have you looked into stinit?
You can set compression in the /etc/stinit.def file.
I have not experimented with modifying compression via stinit, but that is another thing you can try.
FYI: IIRC the package for this is on the DVD, not the CDs.
Greg
I didn't try that because I don't know the density value to pass to stinit. Do you know it?
On 8/11/05, Sebastian Jeremias <ljeremias@lightech.com.ar> wrote:
Greg Freemyer wrote:
Have you looked into stinit?
You can set compression in the /etc/stinit.def file.
I have not experimented with modifying compression via stinit, but that is another thing you can try.
FYI: IIRC the package for this is on the DVD, not the CDs.
Greg
I didn't try that because I don't know the density value to pass to stinit. Do you know it?
A quick google comes up with: # My guess for DDS-4 manufacturer=SONY model = "SDT-10000" { scsi2logical=1 can-bsr can-partitions auto-lock mode1 blocksize=0 compression=1 mode2 blocksize=1024 compression=1 mode3 blocksize=0 compression=0 mode4 blocksize = 1024 compression=0 } That is the entry that goes into /etc/stinit.def Mode1 is the default I think. blocksize=0 means it is variable. compression=1 enables compression. (I think more precise densities can be set here also, but make sure you have compression working first.) If you look at your dmesg output after a boot, you should be able to verify the above manufacturer and model match your drive. the above will only have an impact if you have a stanza like above that matches your drive. Then you typically just call stinit with no args. Greg
On Thu, 2005-08-11 at 19:32 -0400, Greg Freemyer wrote:
On 8/11/05, Sebastian Jeremias <ljeremias@lightech.com.ar> wrote:
I didn't try that because I don't know the density value to pass to stinit. Do you know it?
A quick google comes up with:
# My guess for DDS-4 manufacturer=SONY model = "SDT-10000" { scsi2logical=1 can-bsr can-partitions auto-lock mode1 blocksize=0 compression=1 mode2 blocksize=1024 compression=1 mode3 blocksize=0 compression=0 mode4 blocksize = 1024 compression=0 }
That is the entry that goes into /etc/stinit.def
Mode1 is the default I think. blocksize=0 means it is variable. compression=1 enables compression. (I think more precise densities can be set here also, but make sure you have compression working first.)
If you look at your dmesg output after a boot, you should be able to verify the above manufacturer and model match your drive. the above will only have an impact if you have a stanza like above that matches your drive.
Then you typically just call stinit with no args.
Greg
The OP is asking about the density code for the drive -not- compression setting. I think the density setting has something to do with the amount of data that will fit on a tape (haven't found info yet). On my DDS-3 it is set to 0x25 (unknown) according to the status command. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Thursday 11 August 2005 10:28 pm, Ken Schneider wrote:
On Thu, 2005-08-11 at 19:32 -0400, Greg Freemyer wrote:
On 8/11/05, Sebastian Jeremias <ljeremias@lightech.com.ar> wrote:
I didn't try that because I don't know the density value to pass to stinit. Do you know it?
A quick google comes up with:
# My guess for DDS-4 manufacturer=SONY model = "SDT-10000" { scsi2logical=1 can-bsr can-partitions auto-lock mode1 blocksize=0 compression=1 mode2 blocksize=1024 compression=1 mode3 blocksize=0 compression=0 mode4 blocksize = 1024 compression=0 }
That is the entry that goes into /etc/stinit.def
Mode1 is the default I think. blocksize=0 means it is variable. compression=1 enables compression. (I think more precise densities can be set here also, but make sure you have compression working first.)
If you look at your dmesg output after a boot, you should be able to verify the above manufacturer and model match your drive. the above will only have an impact if you have a stanza like above that matches your drive.
Then you typically just call stinit with no args.
Greg
The OP is asking about the density code for the drive -not- compression setting. I think the density setting has something to do with the amount of data that will fit on a tape (haven't found info yet). On my DDS-3 it is set to 0x25 (unknown) according to the status command.
What do you tell your DAT drive when you stick a DDS-2 tape in it?? I don't tell mine anything and it reads it as a DDS-2. Same thing would happen for writing. DAT drives are smart and don't need to be told what type of tape (DDS-2, 3, 4 etc) you've put in it. At least that's what happens on drives worth their salt.
On Thu, 2005-08-11 at 22:43 -0400, Bruce Marshall wrote:
On Thursday 11 August 2005 10:28 pm, Ken Schneider wrote:
On Thu, 2005-08-11 at 19:32 -0400, Greg Freemyer wrote:
The OP is asking about the density code for the drive -not- compression setting. I think the density setting has something to do with the amount of data that will fit on a tape (haven't found info yet). On my DDS-3 it is set to 0x25 (unknown) according to the status command.
What do you tell your DAT drive when you stick a DDS-2 tape in it??
I don't tell mine anything and it reads it as a DDS-2. Same thing would happen for writing. DAT drives are smart and don't need to be told what type of tape (DDS-2, 3, 4 etc) you've put in it.
At least that's what happens on drives worth their salt.
That's what I would think also. I have never changed the density setting and I don't think you would need/want to. When going through man mt it said to check with the manufacturer for the density code so I think it can be changed. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
2005/8/11, Ken Schneider <suse-list@bout-tyme.net>:
On Thu, 2005-08-11 at 19:32 -0400, Greg Freemyer wrote:
On 8/11/05, Sebastian Jeremias <ljeremias@lightech.com.ar> wrote:
I didn't try that because I don't know the density value to pass to stinit. Do you know it?
A quick google comes up with:
# My guess for DDS-4 manufacturer=SONY model = "SDT-10000" { scsi2logical=1 can-bsr can-partitions auto-lock mode1 blocksize=0 compression=1 mode2 blocksize=1024 compression=1 mode3 blocksize=0 compression=0 mode4 blocksize = 1024 compression=0 }
That is the entry that goes into /etc/stinit.def
Mode1 is the default I think. blocksize=0 means it is variable. compression=1 enables compression. (I think more precise densities can be set here also, but make sure you have compression working first.)
If you look at your dmesg output after a boot, you should be able to verify the above manufacturer and model match your drive. the above will only have an impact if you have a stanza like above that matches your drive.
Then you typically just call stinit with no args.
Greg
The OP is asking about the density code for the drive -not- compression setting. I think the density setting has something to do with the amount of data that will fit on a tape (haven't found info yet). On my DDS-3 it is set to 0x25 (unknown) according to the status command.
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
"The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
By the way, i think it's better to use "mtst" instead of "mt" CI.-
On Thu, 2005-08-11 at 22:46 -0400, Ciro Iriarte wrote:
2005/8/11, Ken Schneider <suse-list@bout-tyme.net>:
On Thu, 2005-08-11 at 19:32 -0400, Greg Freemyer wrote: The OP is asking about the density code for the drive -not- compression setting. I think the density setting has something to do with the amount of data that will fit on a tape (haven't found info yet). On my DDS-3 it is set to 0x25 (unknown) according to the status command.
By the way, i think it's better to use "mtst" instead of "mt"
CI.-
Just did a mtst -f /dev/st0 densities and the correct setting for DDS-4 should be 0x26. The OP I believe had a code of 0x8c EXB-8505 compressed. Perhaps that is why he is having problems fitting all of his data on a single tape. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
From: "Ken Schneider" <suse-list@bout-tyme.net>
Just did a mtst -f /dev/st0 densities and the correct setting for DDS-4 should be 0x26. The OP I believe had a code of 0x8c EXB-8505 compressed. Perhaps that is why he is having problems fitting all of his data on a single tape.
Yes, that's exactly the problem... Yesterday I connected another DAT, that was in another Solaris box. Under Solaris I do a mt status and it says DDS-4. Under Suse, it says EXB-8505, just like the other DAT. I already tryied to use 0x26 density, but it seems to have no effect, because I do a status again and I keep seeing EXB-8505. What I was asking for was the DDS-4 density in bpi, so I can pass it to dump as a command line parameter. Also tryied with stinit, but didn't work. I could change between "default" (0x0) and EXB-8505 (0x8c) densities, and between compression on and off, but no DDS-4 at all. Anyway, I'm already working on a three-levels dump backup schedule :( I'm starting to give up with this... It could be the kernel scsi drivers or the scsi controller (but I don't think so). I already downloaded new "drivers" from HP, but I don't think they are actually "drivers". It's more like a diagnostic application, that didn't help at all... Thanks to all BTW: Ciro, I prefer mtst too :)
On Fri, 2005-08-12 at 14:25 -0300, Sebastian Jeremias wrote:
From: "Ken Schneider" <suse-list@bout-tyme.net>
Just did a mtst -f /dev/st0 densities and the correct setting for DDS-4 should be 0x26. The OP I believe had a code of 0x8c EXB-8505 compressed. Perhaps that is why he is having problems fitting all of his data on a single tape.
Yes, that's exactly the problem... Yesterday I connected another DAT, that was in another Solaris box. Under Solaris I do a mt status and it says DDS-4. Under Suse, it says EXB-8505, just like the other DAT. I already tryied to use 0x26 density, but it seems to have no effect, because I do a status again and I keep seeing EXB-8505. What I was asking for was the DDS-4 density in bpi, so I can pass it to dump as a command line parameter.
Also tryied with stinit, but didn't work. I could change between "default" (0x0) and EXB-8505 (0x8c) densities, and between compression on and off, but no DDS-4 at all.
Anyway, I'm already working on a three-levels dump backup schedule :( I'm starting to give up with this... It could be the kernel scsi drivers or the scsi controller (but I don't think so).
I haven't used dump in a couple of years but I think I ended up trying different lengths until I found what would work. Started by using a length I knew was too much and worked back until I found one that would work. You can't just use the full compressed amount that the tape says will fit because you never get 2:1 compression. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Thursday 11 August 2005 10:28 pm, Ken Schneider wrote:
The OP is asking about the density code for the drive -not- compression setting. I think the density setting has something to do with the amount of data that will fit on a tape (haven't found info yet). On my DDS-3 it is set to 0x25 (unknown) according to the status command.
--
I don't believe I have ever seen the OP mentioned what type of tape he is using. Is it really DDS-4 tape media?? Or what? -- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 08/11/05 22:50 + +----------------------------------------------------------------------------+ "If a cow laughed, would milk come out her nose?
On Tue, 2005-08-09 at 13:31 -0300, Sebastian Jeremias wrote:
Hi, I'm having troubles compressing a DDS-4 tape. I have an HP C5683A drive, and when I do 'mt -f /dev/nst0 status' (or mtst) I get:
twist:/opt/ltt # mtst -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x8c (EXB-8505 compressed). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN
The problem is that it's not using compression, although it's turned on. My questions are: - Is EXB-8505 the right compression mode? I read you could change it to DDS-4, but what's the compression code for DDS-4? - Do I need a hardware specific driver for the SCSI controller for the O.S. to recognize the tape in the proper way? - Something I'm missing?
Thanks in advance, Sebastian Try this command instead:
mt -f /dev/st0 datcompression to see the status of compression. Use mt -f /dev/st0 datcompression 2 to turn it on. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken Schneider wrote:
Try this command instead:
mt -f /dev/st0 datcompression
to see the status of compression. Use mt -f /dev/st0 datcompression 2 to turn it on.
I've already checked that out: twist:~ # mt -f /dev/st0 datcompression Compression on. twist:~ # That's why I think what's wrong is the density it's using, since it's EXB-8505 and should be DDS-4.
On Tuesday 09 August 2005 01:42 pm, Sebastian Jeremias wrote:
Ken Schneider wrote:
Try this command instead:
mt -f /dev/st0 datcompression
to see the status of compression. Use mt -f /dev/st0 datcompression 2 to turn it on.
I've already checked that out: twist:~ # mt -f /dev/st0 datcompression Compression on. twist:~ #
That's why I think what's wrong is the density it's using, since it's EXB-8505 and should be DDS-4.
Tapes are usually identified specifically by the hardware. For example a DDS-3 tape vs. a DDS-4. Personally I don't think I would worry about it. Have you tried to see how much data it will hold?
participants (5)
-
Bruce Marshall -
Ciro Iriarte -
Greg Freemyer -
Ken Schneider -
Sebastian Jeremias