Ubifs? Better Filesystem For Flash Devices?


timofonic

GP Mafia
Joined
May 20, 2004
Messages
399
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.
 
fusion_power said:
Is it compatible with Windows? (File transfer Win-->SD)
You didn't understand about what this mean, this is targeted for flash memories like the 256mb on Pandora or SSD and not consumer SD cards. It seems it can be used usb flash drivers and SD cards too but I didn't look at it in depth.

Kevin_H said:
It looks like it won't be production ready till next year.
Maybe earlier, as this is a paid development by Nokia and it seems quite usable right now.

I just wanted to ask about it it can have technical advantages and direct consequences to the end user like faster boot/suspend/resume process and faster file accessing.

It seems it's better to ask to the Pandora devs directly about this, as this channel is too polluted and ignored by the technical gurus.
 
Last edited by a moderator:
timofonic said:
You didn't understand about what this mean, this is targeted for flash memories like the 256mb on Pandora or SSD and not consumer SD cards. It seems it can be used usb flash drivers and SD cards too but I didn't look at it in depth.
If it's a bolt-on on top of the UBI driver layer, it's going to be...clumsy...for most SD situations, solid state disks, and for any USB thumb drives. The UBI layer is an MTD layer block device interface that's designed to handle erasure of blocks, bad-blocks, and wear leveling on top of an expanse of NAND or NOR flash memory with no disk-like interfaces to it. SD doesn't work that way in most situations and USB thumb drives and SSD's work with a disklike interface that handles the wear leveling for you. To get JFFS2 and UBIFS to work on those devices you have to fake out the MTD layer with a block to MTD emulation driver, which adds overhead and bloat.

It might be a good fit for the on-board flash, though- if it's not a solid state disk. I'm a bit leery of a reliance on a new FS without trying it first, though- so I'm a fence-sitter, because I'd have to diddle with it on a few projects to see how it works on things like Disk on Chip devices. It offers some awesome advantages over JFFS2 from reading about it, but unless it's fully gelled, you could end up with a mess.
 
Last edited by a moderator:
I'm not sure what you hope to gain by using a new and unproven file system for the internal flash memory. For most users, the internal memory will only contain the OS and maybe a handful of frequently used utilities. It is not likely to see frequent modification. As for boot speed increases, how often do you plan to reboot? With all the suspend options we have, I don't expect to reboot for anything less than an OS update or a severe crash.
 
Back
Top