Linus Torvalds wrote:
quoted text
> 
> 
> But it should be *trivial* to compress the metadata too if the code just 
> were to put the metadata at the beginning of the image, and the real data 
> at the end, and then you can build up the image from both ends and you 
> *can* have a fixed starting point for the data (up at the top of the 
> image) even though you are changing the size of the metadata by 
> compression.
> 

I decided to compress the metadata when I designed Squashfs, a read-only 
filesystem which was inspired by Cramfs. Squashfs stores the data at the 
front of the filesystem and puts the metadata at the end, so the data is 
always at a fixed point.  Doing that and a couple of other things allows 
the metadata to be built up and compressed in one-pass while the 
filesystem is being created.  The metadata is split into an inode table 
and a directory table and compressed separately because it compresses 
better than way.

quoted text
> But I literally designed and wrote the thing in a couple of days, and I 
> really didn't think it through right. As a result, the metadata may be 
> dense, but it's totally uncompressed. It would have been better to allow a 
> less dense basic format (allowing bigger uid/gid values, and offsets and 
> file sizes), but compress it.
> 

Squashfs stores much more metadata information, but as it is compressed 
it is much smaller than Cramfs.  Typically the inode table compresses
to less than 40% and the directory table to less than 50%.


quoted text
> So a "v2" cramfs would be a great idea.

That is what I always considered Squashfs to be.  But I also made the 
mistake of making Squashfs both little and big endian.  That's going to
be fixed and then I'll make a second attempt at submitting it for
inclusion in the mainline kernel.

Phillip


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html