UBIFS

UBIFS
Developer(s) Nokia with help of University of Szeged
Full name Unsorted Block Image File System
Introduced 2008 with Linux kernel 2.6.27
Structures
Directory contents B+ trees
Limits
Allowed characters in filenames Any byte except NUL and forward slash "/"
Features
Forks Yes
Attributes Yes
File system permissions POSIX
Other
Supported operating systems Linux

The Unsorted Block Image File System (UBIFS) is a successor to JFFS2, and competitor to LogFS,[1] as a file system for use with raw flash memory media.[2] Development began in earnest in 2007, with the first stable release made to Linux kernel 2.6.27 in October 2008.[3] The file system is developed by Nokia engineers with help of the University of Szeged, Hungary.

Note that UBIFS works on top of an unsorted block images (UBI) device, which is itself on top of a memory technology device (MTD). MTDs are not to be used directly.[4] 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 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) or LZO.

JFFS2 stores filesystem indexes in memory whereas UBIFS stores indexes in flash.[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.

Unsorted Block Images

Unsorted block images (UBI)[10] is an erase block management layer for flash memory devices. UBI serves two purposes, tracking NAND flash 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 flash erase blocks. UBI was written specifically for UBIFS so that it 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.

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

External links

References

  1. ↑ Jonathan Corbet (2 April 2008). "UBIFS".
  2. ↑ UBIFS does not work on top of block devices, only raw flash,
  3. ↑ UBIFS patch submission
  4. ↑ Three layers are involved, MTD, UBI, UBIFS
  5. ↑ http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback
  6. ↑ Why df reports too little free space
  7. ↑ http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability Scalability of UBIFS vs. JFFS2
  8. 1 2 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 Documentation".
  11. ↑ "UBI fastmap making its way to mainline".
  12. ↑ "UBI: Fastmap request for inclusion".
This article is issued from Wikipedia - version of the Monday, October 19, 2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.