On Fri, 30 Dec 2005, Angus MacGyver wrote:
<snip>
[root@hostname data_backups]# du -sh *
19G data
17G data.tar.gz
Ok, so whatever you have in data is only compressible by 11% using gzip,
it's entirely possible that the compression algorythm used by your tape
drive actually end up making it larger.
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
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@xxxxxxxxxxxxxxxxxxxx
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
