Andi Drebes wrote:
Indeed, this is the problem. The readme file fs/cramfs/README states:
"One part of that is addressing endianness. The two options here are
`always use little-endian' (like ext2fs) or `writer chooses
endianness; kernel adapts at runtime'. Little-endian wins because of
code simplicity and little CPU overhead even on big-endian machines."
Unfortunately, the better idea was never implemented. Further, there's no
information about the endianness stored in the filesystem. Guessing it and
mounting the filesystem isn't a clean solution. Even worse, there's no
information about which compression algorithm was used to create the
filesystem. Guessing the compression method may lead to serious problems.
So here is my proposal for future development of cramfs:
The should tell cramfs how to mount a filesystem. Therefore, the endianness
and the compression method both have to be specified manually. If none is
specified, cramfs will assume host endianness and that deflate can be used in
order to decompress the contents. If something seems to be wrong with the
filesystem (e.g. wrong magic), cramfs will guess the endianness and inform
the user about the guess, but it won't mount the filesystem if it doesn't
match the endianness specified or the host's one.
What about simply deep-sixing cramfs and replacing it with squashfs or
something else?
-hpa
-
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
