| Type | |||
| symbolic links | 187 | ||
| regular files | 236 | ||
| device special files | 80 | ||
| directories | 57 |
Comparison of Data storage efficiency of different filesystems with compreseed and uncompressed tar archive (.tar .tar.gz .tar.bz2) not taking filesystem overhead (journal managment, superblock copies etc) into account. The difference between filesystems is due to internal fragmentation and padding of the files.
| Bytes Used | Type | Media Usage | ||
| 1010529 | minirtl_fs.tar.bz2 | 30.42% | ||
| 1092819 | minirtl_fs.tar.gz | 32.89% | ||
| 1277952 | minirtl_fs.cramfs.img | 38.47% | ||
| 1409368 | minirtl_fs.jffs2.img | 42.42% | ||
| 2756540 | minirtl_fs.jffs.img | 82.98% | ||
| 2950144 | minirtl_fs.ext2 | 88.81% | ||
| 2950144 | minirtl_fs.ext3 | 88.81% | ||
| 2960384 | minirtl_fs.minix | 89.11% | ||
| 3061760 | minirtl_fs.tar | 92.17% | ||
| 3321856 | minirtl_fs.reiserfs | 100.00% |
The second comparison takes the effectiv filesystem overhead into account - that is what amount of a storage device is actually available if the media has a raw size of 4096 KB.
| Type | FS-Size | Meta | Nete | effi- | ||
| Data | Size | ciency | ||||
| msdos | 4072 | 0 | 4072 | 99.41% | ||
| jffs (NAND) | 4096 | 48 | 4048 | 98.82% | ||
| minix | 4049 | 1 | 4048 | 98.82% | ||
| jffs2 (NAND) | 4096 | 160 | 3936 | 96.10% | ||
| jffs (NOR) | 4096 | 192 | 3904 | 95.31% | ||
| ext2 | 3963 | 1 | 3758 | 91.74% | ||
| jffs2 (NOR) | 4096 | 640 | 3456 | 84.60% | ||
| ext3 | 3963 | 1043 | 2716 | 66.30% |
Reiserfs and jfs was not taken into account as you can't use it on a 4MB medium any way, the overhead of jffs and jffs2 is hard to account for - documentation for jffs2 state that the garbage collection overhead is 5 erase blocks amounting to 48K for NAND and 640K for NOR Flash (for typical block sizes of 8K and 128K respectively).
Last it should be noticed that most Linux file-systems have options available during formating operations that allow to optimize usage, inde numbers, superblock copies etc. for embedded systems it pays of to give these options a close look. At the same time it must be warned that playing carlessly with such options can result in loss of compatibility (for instance restricting the name-length to 14 chars in minixfs would probably break things quite frequently) and can touch security oissues aswell. As an example one can consider optimizing a file-system by limiting the number of inodes created or setting the reserved disk-space for root to 0, this should only be done if it is posible to guarantee that such settings will not result in system failurs (e.g. on read-only used filesystems this should be safe).
To get the real size requirements of the media one needs to take both factors, compression (or storage efficiency) and filesystem overhead into account. Further it should be noted that for all filesystems accetp for cramfs, jffs, and jffs2 one must take an additional layer (FTL/NFTL for NOR/NAND respectively) into account which reduce the effectively available media size in the range of 5% to 10% .
It is not posible to cover all potential option/filesystem/hardware interactions here - the generall view should though come through: Linux is well suited for embedded systems at the file-system layer but one should not relie on defaults as these generally are not tuned to minimum systems or highly optimized systems but are tuned to robustness with respect to the untrained (desk-top) user, that is many options are set for reserving sotrage are for the root user and for superblock copies etc. that can not be safely ignored in standard setups. For designs that take these reduced filesystems setting into account a safe and roboust filesystem can be constructed though.