DAT/DDS tape backups...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ok, this seems like a simple question, tho I cannot find an answer
anywhere...


Take one DDS-4 tape drive, in this case a Compaq TSL-10000 which is a
DDS-4 drive complete with a 8 tape cassette autoloader.
(basically a re-badged Sony 10000 autoloader)

These devices are supposed to be 20G/40G.

Granted, I am probably never gonna get 40G on one of these tapes, and i
can live with that....
....but surely I should be able to get 20G...

Setup is as follows.

On board SCSI Card, external TSL-10000 autoloader.
Cabling is perfect, and terminated correctly (I do a lot of work with
SCSI at home and at work, I know what I'm doing there)

Stick a DDS2 tape in the drive, and do a backup using dump, I get 
DUMP: Volume 1 3924430 blocks (3832.45MB)

OK, fairly reasonable I guess, would prefer closer to the actual value
of 4G, but...

Turn the compression on via mt, 
[root@hostname ~]# mt -f /dev/st0 compression 1

And do the same thing to the SAME TAPE I just dumped to
and ....  

DUMP: Volume 2 3543529 blocks (3460.48MB)


That is less data, on a tape that I have just put more on..

I was 
1) Expecting more data, 
... and
2) Expecting it to go faster...
 (i.e. send more data to the drive, the drive compresses it and put to
tape)

At least that is how the specifications for these drives (and all
DAT/DDS drives is written)


When I use DDS-4 tapes, basically the same thing happens.

With compression turned off, I get 19459MB to tape, with it on, I get
18559MB...

I don't mind hugely that I get slightly less on a tape that spec'ed
(i.e. 19.5 GB compared to the spec'ed 20GB) due to the manufacturer's
statement of 20G means 20,000,000,000 not 20*1024*1024*1024......

..... but what i do mind is that whilst I understand that the
compression is never going to be 2:1 as the
salesman^H^H^H^H^H^H^H^HManufacturer states, I do mind that I can get
LESS on with the compression turned on!!...

Google has been somewhat less than helpful, and I have spent a good few
days at this.

man mt, man st really all don't shed light on the "issue" 

That actual data are the directories data/ and mail/, and before anyone
asks, the tar.gz's below were created to proove that the data did at
least compress by some amount (I know if you compress already compressed
data it can get bigger)

[root@hostname data_backups]# du -sh *
19G     data
17G     data.tar.gz
1.9G    mail
494M    mail.tar.gz

There is only actually 21G in the directories of data/ and mail/ and I
kinda think i should be able to get 21G on to a tape with compression
turned on...


Whilst I am here, i can also say that it isn't the hardware, as i have
another tape drive, a DDS-5 (36/72) that does exactly the same thing
with these tapes..

The tapes I am using are brand new, so should not have lost any
capacity.

This machine is a Fedora core 3, and some details below..


[root@hostname ~]# uname -a
Linux hostname.somewhere 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04:03:26
EDT 2005 i686 i686 i386 GNU/Linux


[root@hostname ~]# mt -v
mt-st v. 0.8

[root@hostname ~]# dump
dump 0.4b39 (using libext2fs 1.35 of 28-Feb-2004)


[root@hostname ~]# cat /etc/stinit.def
# DDS-4 Guestimate
manufacturer=COMPAQ model = "TSL-10000" {
scsi2logical=0 can-bsr can-partitions auto-lock
mode1 blocksize=0 density=0x26 compression=0      # 20GB noC
mode2 blocksize=512 density=0x26 compression=0    # 20GB + Compression
mode3 blocksize=512 density=0x26 compression=1    # 20GB no Compression
mode4 blocksize=0 density=0x26 compression=1 }    # 20GB + Compression


Can anyone shed some light on this please???

Regards
AM


-- 
Angus MacGyver <macgyver@xxxxxxxxxxxxxxxxxxxxxxx>


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux