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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
