Re: [PATCH 04/10] AXFS: axfs_inode.c

From: Phillip Lougher
Date: Fri Aug 22 2008 - 13:08:53 EST


Arnd Bergmann wrote:
On Friday 22 August 2008, Phillip Lougher wrote:
This looks very nice, but could use some comments about how the data is
actually stored on disk. It took me some time to figure out that it actually
allows to do tail merging into compressed blocks, which I was about to suggest
you implement ;-). Cramfs doesn't have them, and I found that they are the
main reason why squashfs compresses better than cramfs, besides the default
block size, which you can change on either one.
Squashfs has much larger block sizes than cramfs (last time I looked it was limited to 4K blocks), and it compresses the metadata which helps to get better compression. But tail merging (fragments in Squashfs terminology) is obviously a major reason why Squashfs gets good compression.

The *default* block size in cramfs is smaller than in squashfs, but they both
have user selectable block sizes. I found the impact of compressed metadata
to be almost zero.

Squashfs stores significantly more metadata than cramfs. Remember cramfs has no support for filesystems > ~ 16Mbytes, no inode timestamps, truncates uid/gids, no hard-links, no nlink counts, no hashed directories, no unique inode numbers. If Squashfs didn't compress the metadata it would be significantly larger than cramfs.

Cheers

Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/