Hello.
What about UbiFS? It's developed by Nokia and it seems better than other alternatives like JFFS2, LogFS (not production ready), YAFFS2.
QUOTE
UBIFS is a new flash file system which is designed to work on top of UBI. The file system is developed by Nokia engineers with help of the University of Szeged.
UBIFS works on top of UBI volumes, it cannot operate on top of MTD devices. In other words, there are 3 subsystems involved:
* MTD subsystem, which provides a uniform interface to access flash chips. MTD provides a notion of MTD devices (e.g., /dev/mtd0) which basically provide access to the raw flash;
* UBI subsystem, which is a volume management system for flash devices; UBI works on top of MTD devices and provides a notion of UBI volumes; UBI volumes are more "high level" entities than MTD devices and they are devoid of many unpleasant issues MTD devices have (e.g., wearing and bad blocks); See here for more information;
* UBIFS file-system, which works on top of UBI volumes.
In contrast, JFFS2 file-system works on top of raw MTD devices.
The main objectives of UBIFS are:
1. better scalability comparing to what JFFS2 provides, which is achieved by storing and maintaining the indexing data structures of the file-system on the flash media;
2. write-back support;
3. support of on-the-flight compression.
QUOTE
UBI (Latin: "where?") stands for "Unsorted Block Images". It is a volume management system for flash devices which manages multiple logical volumes on a single physical flash device and spreads the I/O load (i.e, wear-leveling) across the whole flash chip.
In a sense, UBI may be compared to the Logical Volume Manager (LVM). Whereas LVM maps logical sectors to physical sectors, UBI maps logical eraseblocks to physical eraseblocks. But besides the mapping, UBI implements global wear-leveling and I/O errors handling.
An UBI volume is a set of consecutive logical eraseblocks. Each logical eraseblock may be mapped to any physical eraseblock. This mapping is managed by UBI, it is hidden from users and it is the base mechanism to provide global wear-leveling (along with per-physical eraseblock erase counters and the ability to transparently move data from more worn-out physical eraseblocks to the less worn-out ones).
UBI volume size is specified when the volume is created a may later be changed (volumes are dynamically re-sizable). UBI supports dynamic volumes and static volumes. Static volumes are read-only and their contents are protected by CRC check sums, while dynamic volumes are read-write and the upper layer (e.g., a file-system) is responsible for data integrity.
UBI is aware of bad eraseblocks (e.g., NAND flash may have them) and frees the upper layer from any bad block handling. UBI has a pool of reserved physical eraseblocks, and when a physical eraseblock becomes bad, it transparently substitutes it by a good physical eraseblock. UBI moves good data from the newly appeared bad physical eraseblock to the good one as well. The result is that users of UBI volumes do not notice I/O errors as UBI takes care of them.
NAND flashes may have bit-flips which occur on read and write operations. Bit-flips are corrected by ECC checksums, but they may accumulate over time and cause data loss. UBI handles this by moving data from physical eraseblocks with bit-flips to other physical eraseblocks, thus doing active scrubbing. This is done transparently in background and is hidden from upper layers.
QUOTE
"Ubi scales linearly, as it does a large scan at init time. It is still reasonably fast, as it reads just a few bytes worth of header per block. Logfs mounts in O(1) but will currently become mindbogglingly slow when the filesystem nears 100% full and write are purely random. Not that any other flash filesystem would perform well under these conditions - it is the known worst case scenario."
http://kerneltrap.org/Linux/UBI_File_System
http://kerneltrap.org/Linux/Comparing_UBIFS_And_LogFS
http://osl.sed.hu/wiki/ubifs/
http://www.linux-mtd.infradead.org/doc/ubifs.html
http://www.linux-mtd.infradead.org/faq/ubifs.html
http://www.linux-mtd.infradead.org/doc/ubi.html
http://www.linux-mtd.infradead.org/faq/ubi.html
Regards.
What about UbiFS? It's developed by Nokia and it seems better than other alternatives like JFFS2, LogFS (not production ready), YAFFS2.
QUOTE
UBIFS is a new flash file system which is designed to work on top of UBI. The file system is developed by Nokia engineers with help of the University of Szeged.
UBIFS works on top of UBI volumes, it cannot operate on top of MTD devices. In other words, there are 3 subsystems involved:
* MTD subsystem, which provides a uniform interface to access flash chips. MTD provides a notion of MTD devices (e.g., /dev/mtd0) which basically provide access to the raw flash;
* UBI subsystem, which is a volume management system for flash devices; UBI works on top of MTD devices and provides a notion of UBI volumes; UBI volumes are more "high level" entities than MTD devices and they are devoid of many unpleasant issues MTD devices have (e.g., wearing and bad blocks); See here for more information;
* UBIFS file-system, which works on top of UBI volumes.
In contrast, JFFS2 file-system works on top of raw MTD devices.
The main objectives of UBIFS are:
1. better scalability comparing to what JFFS2 provides, which is achieved by storing and maintaining the indexing data structures of the file-system on the flash media;
2. write-back support;
3. support of on-the-flight compression.
QUOTE
UBI (Latin: "where?") stands for "Unsorted Block Images". It is a volume management system for flash devices which manages multiple logical volumes on a single physical flash device and spreads the I/O load (i.e, wear-leveling) across the whole flash chip.
In a sense, UBI may be compared to the Logical Volume Manager (LVM). Whereas LVM maps logical sectors to physical sectors, UBI maps logical eraseblocks to physical eraseblocks. But besides the mapping, UBI implements global wear-leveling and I/O errors handling.
An UBI volume is a set of consecutive logical eraseblocks. Each logical eraseblock may be mapped to any physical eraseblock. This mapping is managed by UBI, it is hidden from users and it is the base mechanism to provide global wear-leveling (along with per-physical eraseblock erase counters and the ability to transparently move data from more worn-out physical eraseblocks to the less worn-out ones).
UBI volume size is specified when the volume is created a may later be changed (volumes are dynamically re-sizable). UBI supports dynamic volumes and static volumes. Static volumes are read-only and their contents are protected by CRC check sums, while dynamic volumes are read-write and the upper layer (e.g., a file-system) is responsible for data integrity.
UBI is aware of bad eraseblocks (e.g., NAND flash may have them) and frees the upper layer from any bad block handling. UBI has a pool of reserved physical eraseblocks, and when a physical eraseblock becomes bad, it transparently substitutes it by a good physical eraseblock. UBI moves good data from the newly appeared bad physical eraseblock to the good one as well. The result is that users of UBI volumes do not notice I/O errors as UBI takes care of them.
NAND flashes may have bit-flips which occur on read and write operations. Bit-flips are corrected by ECC checksums, but they may accumulate over time and cause data loss. UBI handles this by moving data from physical eraseblocks with bit-flips to other physical eraseblocks, thus doing active scrubbing. This is done transparently in background and is hidden from upper layers.
QUOTE
"Ubi scales linearly, as it does a large scan at init time. It is still reasonably fast, as it reads just a few bytes worth of header per block. Logfs mounts in O(1) but will currently become mindbogglingly slow when the filesystem nears 100% full and write are purely random. Not that any other flash filesystem would perform well under these conditions - it is the known worst case scenario."
http://kerneltrap.org/Linux/UBI_File_System
http://kerneltrap.org/Linux/Comparing_UBIFS_And_LogFS
http://osl.sed.hu/wiki/ubifs/
http://www.linux-mtd.infradead.org/doc/ubifs.html
http://www.linux-mtd.infradead.org/faq/ubifs.html
http://www.linux-mtd.infradead.org/doc/ubi.html
http://www.linux-mtd.infradead.org/faq/ubi.html
Regards.
