gzip.First of all, check that the "best" (i.e. most compressing) compression algorithm and cluster size are being used.
$ chattr -c myfile
$ df myfile # Just check that we didn't run out of space.
# Another, surer way of doing this if we have the e2compr
# version of lsattr is `lsattr myfile' and see if an
# algorithm name is still displayed.
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda2 149806 124412 17658 88% /
# ^^^^^
# No, we probably didn't run out of space.
# (see section What if I decompress a file on a full device?)
$ chattr +c -m gzip9 -b 32 myfile
Now take a look at how it compares with straight `gzip -9'.
$ e2ratio -l myfile 1488 721 48.5% myfile $ gzip -9 < myfile > myfile.gz $ du -k myfile.gz 601 /tmp/delme.gz
There is still a difference (721 versus 601 1KB-blocks). This
difference is because e2compr divides a file into "clusters"
---sections of a fixed size (in this case 32KB)--- and compresses each
of those clusters independently: any similarity between the contents of
different clusters will be ignored. The decision to do things this way
was made in order to reduce the amount of time it takes for random
access. (With gzip, there's no way of accessing the last byte of
the decompressed stream without decompressing the whole stream. Other
compression methods, more suitable to random access, are conceivable,
but designing a good compression method is a serious undertaking.)
Go to the first, previous, next, last section, table of contents.