On Wed, 16 Jan 2002 19:22:58 GMT, toad said:

> If you're cpu-bound, you probably don't want to compress anything,
> unless a smaller tail is a lot easier to pack, which the reiserfs docs
> seem to suggest... possibly this won't gain you enough to offset the
> cost of compression though. Benchmarking could be interesting.
> For example, if you have lots of small, compressible files and good
> read locality, read performance could benefit from compression.

Actually, I've found that it can be a performance win.

I've benched the AIX scheme, and found that if your data is mostly-text
(and thus compresses very well), it can often be faster to read 3 512-byte
blocks and decompress it to a 4K logical block than to actually read 4K
off the disk.  This was even with SCSI-1 and a slow (by today's standards) CPU.
With SCSI-2 and a 166mz 604E, the CPU overhead was still only about 1%, and
disk throughput was higher by a good 15%.

I suspect that for IDE/ATA, with its historically higher CPU cost for I/O,
it would be even bigger a win.

> OTOH, it could function as a building block for 'real compression' - a
> directory with an inode flag appears as a file, contains a series of
> small files with numbered names (or ideally without names, write the
> hash directly); each file is a compressed 4kb block (ordinarily this
> would not be stored as a tail, but here it is, after compression).
> This stuff probably gains greatly from a repacker and allocate on
> flush, and would also be cleaner with v4's plugins.

What AIX does is compress each 4K block, and then allocate
only as many 512-byte fragments as are actually needed.

Another idea I've seen is the AIX/370 filesystem, which supported
"small files in inode" - if the total file data was under <insert
number of bytes allocated to inode block pointers>, it wouldn't
allocate any disk blocks, but use the space in the inode for the
actual data. It's the equivalent of the (struct ext2_inode)->i_block[]
array.  Only 64 bytes or so, but it's amazing how often it saved
allocating a 4K block.  Probably not worth doing if you have a
sane tail or fragment storage scheme, however...

/Valdis


Attachment: msg04056/pgp00000.pgp
Description: PGP signature

Reply via email to