Danny, On Tuesday 15 March 2005 08:09, Randall R Schulz wrote:
Danny,
...
I was thinking plain old extfs2, but this cramfs thing sounds interesting. What are the implications / requirements for getting it working on an otherwise stock SuSE 9.1 (with all YOU patches, including new kernels, installed)?
It appears cramfs is very limited, it's rather less than a full-featured Linux file system with compression. Evidently, it's actually oriented towards embedded Linux applications like your (Danny's) MP3 player. For example (from the NOTES file included in the cramfs tools tarball): -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Usage Notes ----------- File sizes are limited to less than 16MB. Maximum filesystem size is a little over 256MB. (The last file on the filesystem is allowed to extend past 256MB.) Only the low 8 bits of gid are stored. The current version of mkcramfs simply truncates to 8 bits, which is a potential security issue. Hard links are supported, but hard linked files will still have a link count of 1 in the cramfs image. Cramfs directories have no `.' or `..' entries. Directories (like every other file on cramfs) always have a link count of 1. (There's no need to use -noleaf in `find', btw.) No timestamps are stored in a cramfs, so these default to the epoch (1970 GMT). Recently-accessed files may have updated timestamps, but the update lasts only as long as the inode is cached in memory, after which the timestamp reverts to 1970, i.e. moves backwards in time. Currently, cramfs must be written and read with architectures of the same endianness, and can be read only by kernels with PAGE_CACHE_SIZE == 4096. At least the latter of these is a bug, but it hasn't been decided what the best fix is. For the moment if you have larger pages you can just change the #define in mkcramfs.c, so long as you don't mind the filesystem becoming unreadable to future kernels. -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- I think I'll stick with ext2fs. Randall Schulz