On Thu, 15 Nov 2007, Andi Drebes wrote: > > Actually, in my eyes, it would be better to create a new version of cramfs > that standardizes the endianness and the block size. Perhaps even more importantly, you can do a much better job. The thing is, when I did cramfs originally, I had a total "senior moment", and the reason I didn't compress the metadata was that it appeared hard to do and fill it in later (ie compressing the metadata would mean that the location of the data changes - and since the metadata obviously contains pointers to the data, there's a chicken-and-egg problem there). 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. 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. So a "v2" cramfs would be a great idea. Not just for fixing endianness etc. Linus - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
