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-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
