UBIFS

UBIFS (UBI File System, more fully Unsorted Block Image File System) is a flash file system for unmanaged flash memory devices.[1] UBIFS works on top of an UBI (unsorted block image) layer,[2] which is itself on top of a memory technology device (MTD) layer.[3] The file system is developed by Nokia engineers with help of the University of Szeged, Hungary. Development began in earnest in 2007, with the first stable release made to Linux kernel 2.6.27 in October 2008. [4]

UBIFS
Developer(s)Nokia with help of University of Szeged
Full nameUnsorted Block Image File System
Introduced2008 (2008) with Linux kernel 2.6.27
Structures
Directory contentsB+ trees
Limits
Allowed filename
characters		Any byte except NUL and forward slash "/"
Features
ForksYes
AttributesYes
File system
permissions		Unix permissions
Transparent
compression		Yes
Other
Supported
operating systems		Linux

Two major differences between UBIFS and JFFS2 are that UBIFS supports write caching,[5] and UBIFS errs on the pessimistic side of free space calculation.[6] UBIFS tends to perform better than JFFS2 for large NAND flash memory devices.[7] This is a consequence of the UBIFS design goals:[8] faster mounting, quicker access to large files, and improved write speeds. UBIFS also preserves or improves upon JFFS2's on-the-fly compression, recoverability and power fail tolerance.[8] UBIFS's on-the-fly data compression allows zlib (deflate algorithm), LZO or Zstandard.

UBIFS stores indexes in flash whereas JFFS2 stores filesystem indexes in memory.[9] This directly impacts the scalability of JFFS2 as the tables must be rebuilt every time the volume is mounted. Also, the JFFS2 tables may consume enough system RAM that some images may be unusable.

UBI

UBI (Unsorted Block Images)[10] is an erase block management layer for flash memory devices. UBI serves two purposes, tracking NAND flash memory bad blocks and providing wear leveling. Wear leveling spreads the erases and writes across the entire flash device. UBI presents logical erase blocks to higher layers and maps these to physical erase blocks. UBI was written specifically for UBIFS so that UBIFS does not have to deal with wear leveling and bad blocks. However, UBI may also be useful with squashfs and NAND flash; squashfs is not aware of NAND flash bad blocks.

UBI's documentation explains that it is not a complete flash translation layer (FTL). Although a FTL also handles bad blocks and wear leveling, the interface a FTL provides is a block device with small (typically 512 bytes) sectors that can be written completely independently. In contrast, UBI's interface directly exposes erase blocks and programmable pages (which are different sizes, and much larger than typical block device sectors), and filesystems that use UBI must be aware of the sizes and restrictions on how blocks must be erased before being written.

UBI is in some ways analogous to a Logical Volume Manager. In typical usage, rather than partitioning flash into fixed regions, a single UBI device spans the entire flash (except for perhaps a few pages in fixed locations reserved for the bootloader), and multiple volumes are created within the UBI device. This allows wear-leveling to be spread across the whole flash, even if some volumes are written more frequently than others. UBI volumes can be static (which contain a whole file or image written once and protected by CRC-32 by UBI) or dynamic (which contain a read-write filesystem that is responsible for its own data integrity). The only filesystem that directly supports UBI is UBIFS, but using gluebi it's possible to emulate a MTD device, which can then be used to run other flash filesystems like JFFS2 and YAFFS, and using ubiblk it's possible to emulate block devices, which can run common filesystems like Ext4.

Fastmap

UBI was augmented in Linux 3.7 with fastmap support.[11][12] Fastmap maintains an on-disk version of information previously created in memory by scanning the entire flash device. The code falls back to the previous mechanism of a full scan on failures and older UBI systems will simply ignore the fastmap information.

See also

References
  1. Jonathan Corbet (2 April 2008). "UBIFS". LWN.net. Retrieved 18 December 2016.
  2. "UBIFS – UBI File-System: Big red note". 22 January 2015. Retrieved 18 December 2016. It does not work on top of block devices. UBIFS was designed to work on top of raw flash.
  3. "UBIFS – UBI File-System: Overview". 22 January 2015. Retrieved 18 December 2016.
  4. Artem Bityutskiy (27 March 2008). "UBIFS – new flash file system". Retrieved 18 December 2016.
  5. "UBIFS – UBI File-System: Write-back support". 22 January 2015. Retrieved 18 December 2016.
  6. "UBIFS FAQ and HOWTO: Why does df report too little free space?". 18 December 2015. Retrieved 18 December 2016.
  7. "UBIFS – UBI File-System: Scalability". 22 January 2015. Retrieved 18 December 2016.
  8. Bityutskiy, Artem; Hunter, Adrian (24 September 2008). "UBIFS File System" (PDF). p. 9.
  9. Adrian Hunter (27 March 2008). "A Brief Introduction to the Design of UBIFS" (PDF).
  10. "UBI – Unsorted Block Images". 22 January 2015. Retrieved 18 December 2016.
  11. Thomas Petazzoni (3 October 2012). "UBI fastmap making its way to mainline". Archived from the original on 15 November 2012. Retrieved 18 December 2016.
  12. Richard Weinberger (24 September 2012). "UBI: Fastmap request for inclusion (v18)". Retrieved 18 December 2016.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.