diff options
| author | Mark Brown <broonie@kernel.org> | 2026-05-29 18:09:44 +0100 |
|---|---|---|
| committer | Mark Brown <broonie@kernel.org> | 2026-05-29 18:09:44 +0100 |
| commit | 10009bb9d1ae89c174a2e0f2132a91822aae42fa (patch) | |
| tree | cd969b50e12639f3ef9dafcce43cca5c3a8e0a89 /fs | |
| parent | 75729570cb18aecca07da172d007478a95e0378e (diff) | |
| parent | d6dd61121cff3aaec3d444e2489c8cc66220c400 (diff) | |
| download | linux-next-history-10009bb9d1ae89c174a2e0f2132a91822aae42fa.tar.gz | |
Merge branch 'docs-next' of git://git.lwn.net/linux.git
Diffstat (limited to 'fs')
| -rw-r--r-- | fs/cramfs/README | 92 |
1 files changed, 1 insertions, 91 deletions
diff --git a/fs/cramfs/README b/fs/cramfs/README index 778df5c4d70bb..c0052a11aa28a 100644 --- a/fs/cramfs/README +++ b/fs/cramfs/README @@ -104,94 +104,4 @@ Tools ----- The cramfs user-space tools, including mkcramfs and cramfsck, are -located at <http://sourceforge.net/projects/cramfs/>. - - -Future Development -================== - -Block Size ----------- - -(Block size in cramfs refers to the size of input data that is -compressed at a time. It's intended to be somewhere around -PAGE_SIZE for cramfs_read_folio's convenience.) - -The superblock ought to indicate the block size that the fs was -written for, since comments in <linux/pagemap.h> indicate that -PAGE_SIZE may grow in future (if I interpret the comment -correctly). - -Currently, mkcramfs #define's PAGE_SIZE as 4096 and uses that -for blksize, whereas Linux-2.3.39 uses its PAGE_SIZE, which in -turn is defined as PAGE_SIZE (which can be as large as 32KB on arm). -This discrepancy is a bug, though it's not clear which should be -changed. - -One option is to change mkcramfs to take its PAGE_SIZE from -<asm/page.h>. Personally I don't like this option, but it does -require the least amount of change: just change `#define -PAGE_SIZE (4096)' to `#include <asm/page.h>'. The disadvantage -is that the generated cramfs cannot always be shared between different -kernels, not even necessarily kernels of the same architecture if -PAGE_SIZE is subject to change between kernel versions -(currently possible with arm and ia64). - -The remaining options try to make cramfs more sharable. - -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. - -The cost of swabbing is changing the code to use the le32_to_cpu -etc. macros as used by ext2fs. We don't need to swab the compressed -data, only the superblock, inodes and block pointers. - - -The other part of making cramfs more sharable is choosing a block -size. The options are: - - 1. Always 4096 bytes. - - 2. Writer chooses blocksize; kernel adapts but rejects blocksize > - PAGE_SIZE. - - 3. Writer chooses blocksize; kernel adapts even to blocksize > - PAGE_SIZE. - -It's easy enough to change the kernel to use a smaller value than -PAGE_SIZE: just make cramfs_read_folio read multiple blocks. - -The cost of option 1 is that kernels with a larger PAGE_SIZE -value don't get as good compression as they can. - -The cost of option 2 relative to option 1 is that the code uses -variables instead of #define'd constants. The gain is that people -with kernels having larger PAGE_SIZE can make use of that if -they don't mind their cramfs being inaccessible to kernels with -smaller PAGE_SIZE values. - -Option 3 is easy to implement if we don't mind being CPU-inefficient: -e.g. get read_folio to decompress to a buffer of size MAX_BLKSIZE (which -must be no larger than 32KB) and discard what it doesn't need. -Getting read_folio to read into all the covered pages is harder. - -The main advantage of option 3 over 1, 2, is better compression. The -cost is greater complexity. Probably not worth it, but I hope someone -will disagree. (If it is implemented, then I'll re-use that code in -e2compr.) - - -Another cost of 2 and 3 over 1 is making mkcramfs use a different -block size, but that just means adding and parsing a -b option. - - -Inode Size ----------- - -Given that cramfs will probably be used for CDs etc. as well as just -silicon ROMs, it might make sense to expand the inode a little from -its current 12 bytes. Inodes other than the root inode are followed -by filename, so the expansion doesn't even have to be a multiple of 4 -bytes. +located at <https://github.com/npitre/cramfs-tools>. |