What choices for filesystem are there at all?
Filesystems optimized for Flash's?
At the end of this article
http://www-106.ibm.com/developerworks/library/l-embdev.htmlis a little overview. They recommend not to use ext2 but jffs2 (I am not familiar with which roms support that out of the box though). To quote some of this:
The second Extended Filesystem (Ext2fs)
Ext2fs is the de facto standard filesystem for Linux, having ousted its predecessor, the Extended File System (or Extfs). Extfs supported a maximum file size of 2 gigabytes and a maximum file name size of 255 characters -- and it did not support inodes (including data modification timestamps). Ext2fs does much better; it has these advantages:
* Ext2fs supports up to 4 terabytes of memory.
* Ext2fs filenames can be up to 1012 characters in length.
* The administrator can choose the logical block size when creating the filesystem (typical sizes are 1024, 2048, and 4096 bytes).
* Ext2fs implements fast symbolic links: no data blocks need to be allocated for this purpose, and the target name is directly stored in the inode table. This leads to an increase in performance, especially in speed.
Because of its stability, reliability, and robustness, the Ext2 filesystem is used on almost all Linux-based systems including desktops, servers, and workstations -- and even some embedded devices. However, Ext2fs has some disadvantages when it comes to embedded devices:
* Ext2fs is designed for block devices like IDE devices, where the logical block size will be on the order of 512 bytes, 1 kilobyte, and so on. This is not well suited for flash devices where sector sizes vary.
* The Ext2 filesystem does not provide good management of sector-based erase/writes. To erase a single byte in a sector in Ext2fs, a whole sector has to be copied to RAM, erased, then rewritten. Considering that flash devices have a limited erase lifecycle (about 100,000 erases) after which they can't be used, this is not a particularly good practice.
* Ext2fs is not crash-proof in the case of a power failure.
* The Ext2 filesystem does not support wear levelling, thereby reducing sector/flash life. (Wear levelling ensures that different areas of the address range are used for writes and/or erases in rotation to extend flash life.)
* Ext2fs does not have particularly brilliant sector management, making the designing of a block driver extremely difficult.
For these reasons, an MTD/JFFS2 combination is generally preferred over Ext2fs for the embedded environment.
---------------------------------------------------
Journaling Flash File System, version 2 (JFFS2)
The original JFFS was developed by Axis Communications of Sweden, and was improved upon by David Woodhouse at Red Hat. The second version, JFFS2, is emerging as the de facto filesystem for raw flash chips for tiny embedded devices. The JFFS2 filesystem is log-structured, meaning that it is basically a long list of nodes. Each node contains some information about the file of which it is part -- possibly the name of the file, maybe some data. JFFS2 is being increasingly favored over Ext2fs for diskless embedded devices for these advantages:
* JFFS2 performs flash erase/write/read on the sector level better than the Ext2 filesystem.
* JFFS2 provides better crash/power-down-safe protection than Ext2fs. When a little amount of data needs to be changed, the Ext2 filesystem copies the whole sector to memory (DRAM), merges the new data in memory, and writes back the whole sector. This means that for changing a single word, the read/erase/write routine has to be done for the whole (64 KB) sector -- which is highly inefficient. On the off chance that there is a power failure or other catastrophe while data is being merged in DRAM, the entire collection of data is lost, since the flash sector is erased after the data has been read to DRAM. JFFS2 appends files rather than rewriting whole sectors, and features crash/power-done-safe protection.
* Perhaps most importantly, JFFS2 was specifically created for embedded devices like flash chips, so its overall design provides better flash management.
Having been written primarily for use with flash devices, the disadvantages of using JFFS2 in an embedded environment are few:
* JFFS2 can tend to slow down a great deal when the filesystem is full or nearly full. This is because of garbage collection issues (see Resources for more information).
-------------------------------------------------------------
tmpfs
Once an embedded device becomes a fully functional unit with Linux running on top of it, lots of daemons tend to run in the background generating lots of log messages. In addition, all of the kernel logging mechanisms like syslogd, dmesg, and klogd, generate a lot of messages under the /var and /tmp directories. Since a huge amount of data is produced by these processes, it is not advisable to allow all of these writes to happen to flash. As these messages need not be persistent across reboots, the solution to this problem is to use tmpfs.
Tmpfs is a memory-based filesystem, which is mainly used for the sole purpose of reducing unnecessary flash writes to the system. Since tmpfs resides in RAM, operations to write/read/erase happen in RAM rather than in flash. Therefore, log messages go to RAM rather than to flash, and they are not preserved across reboots. Tmpfs also makes use of the disk swap space for storage, and of the virtual memory (VM) subsystem when requesting pages for storing files.
Advantages of tmpfs include:
* Dynamic filesystem size -- The filesystem size can shrink or grow depending on the number of files or directories that are copied or created or deleted. This results in optimal usage of memory.
* Speed -- As tmpfs resides in RAM, the reads and writes are almost instantaneous. Even if files are stored in swap, the I/O operations are at very high speed.
One disadvantage of tmpfs is that all data is lost when the system reboots. Therefore, important data can't be stored on tmpfs.
Poll