UBIFS

Last updated

UBIFS
Developer(s) Nokia with help of University of Szeged
Full nameUnsorted Block Image File System
Introduced2008;15 years ago (2008) with Linux kernel 2.6.27
Structures
Directory contents B+ trees
Limits
Allowed filename
characters
Any byte except NUL and forward slash "/"[ citation needed ]
Features
Forks Yes
AttributesYes
File system
permissions
Unix permissions
Transparent
compression
Yes
Other
Supported
operating systems
Linux

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]

Contents

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

Related Research Articles

<span class="mw-page-title-main">Flash memory</span> Electronic non-volatile computer storage device

Flash memory is an electronic non-volatile computer memory storage medium that can be electrically erased and reprogrammed. The two main types of flash memory, NOR flash and NAND flash, are named for the NOR and NAND logic gates. Both use the same cell design, consisting of floating gate MOSFETs. They differ at the circuit level depending on whether the state of the bit line or word lines is pulled high or low: in NAND flash, the relationship between the bit line and the word lines resembles a NAND gate; in NOR flash, it resembles a NOR gate.

Wear leveling is a technique for prolonging the service life of some kinds of erasable computer storage media, such as flash memory, which is used in solid-state drives (SSDs) and USB flash drives, and phase-change memory. There are several wear leveling mechanisms that provide varying levels of longevity enhancement in such memory systems.

<span class="mw-page-title-main">Linear Flash</span>

Linear Flash is a PC card flash memory format. Linear Flash requires no battery support, unlike somewhat faster SRAM, and features read/write speeds much faster than similar, less expensive ATA-type cards, which include CompactFlash and Memory Stick. Like an SRAM, Linear Flash supports execute in place (XIP) applications in mobile PC and embedded equipment.

Journalling Flash File System version 2 or JFFS2 is a log-structured file system for use with flash memory devices. It is the successor to JFFS. JFFS2 has been included into the Linux kernel since September 23, 2001, when it was merged into the Linux kernel mainline as part of the kernel version 2.4.10 release. JFFS2 is also available for a few bootloaders, like Das U-Boot, Open Firmware, the eCos RTOS, the RTEMS RTOS, and the RedBoot. Most prominent usage of the JFFS2 comes from OpenWrt.

Yaffs is a file system designed and written by Charles Manning for the company Aleph One.

Squashfs is a compressed read-only file system for Linux. Squashfs compresses files, inodes and directories, and supports block sizes from 4 KiB up to 1 MiB for greater compression. Several compression algorithms are supported. Squashfs is also the name of free software, licensed under the GPL, for accessing Squashfs filesystems.

<span class="mw-page-title-main">Das U-Boot</span> Open-source, primary boot the devices operating system kernel

Das U-Boot is an open-source, primary boot loader used in embedded devices to package the instructions to boot the device's operating system kernel. It is available for a number of computer architectures, including 68k, ARM, Blackfin, MicroBlaze, MIPS, Nios, SuperH, PPC, RISC-V and x86.

<span class="mw-page-title-main">Solid-state drive</span> Data storage device

A solid-state drive (SSD) is a solid-state storage device that uses integrated circuit assemblies to store data persistently, typically using flash memory, and functioning as secondary storage in the hierarchy of computer storage. It is also sometimes called a semiconductor storage device, a solid-state device or a solid-state disk, even though SSDs lack the physical spinning disks and movable read–write heads used in hard disk drives (HDDs) and floppy disks. SSD also has rich internal parallelism for data processing.

<span class="mw-page-title-main">Memory Technology Device</span> Type of device file in Linux for interacting with flash memory

A Memory Technology Device (MTD) is a type of device file in Linux for interacting with flash memory. The MTD subsystem was created to provide an abstraction layer between the hardware-specific device drivers and higher-level applications. Although character and block device files already existed, their semantics don't map well to the way that flash memory devices operate.

LogFS is a Linux log-structured and scalable flash file system, intended for use on large devices of flash memory. It is written by Jörn Engel and in part sponsored by the CE Linux Forum.

AXFS is a compressed read-only file system for Linux, initially developed at Intel, and now maintained at Numonyx. It was designed to use execute in place (XIP) alongside compression aiming to reduce boot and program load times, while retaining a small memory footprint for embedded devices. This is achieved by mixing compressed and uncompressed pages in the same executable file. AXFS is free software.

A flash file system is a file system designed for storing files on flash memory–based storage devices. While flash file systems are closely related to file systems in general, they are optimized for the nature and characteristics of flash memory, and for use in particular operating systems.

<span class="mw-page-title-main">Write amplification</span> Phenomenon associated with solid state storage

Write amplification (WA) is an undesirable phenomenon associated with flash memory and solid-state drives (SSDs) where the actual amount of information physically written to the storage media is a multiple of the logical amount intended to be written.

<span class="mw-page-title-main">Flash memory controller</span> Integrated circuit that interfaces flash memory to a host like a PC

A flash memory controller manages data stored on flash memory and communicates with a computer or electronic device. Flash memory controllers can be designed for operating in low duty-cycle environments like memory cards, or other similar media for use in PDAs, mobile phones, etc. USB flash drives use flash memory controllers designed to communicate with personal computers through the USB port at a low duty-cycle. Flash controllers can also be designed for higher duty-cycle environments like solid-state drives (SSD) used as data storage for laptop computer systems up to mission-critical enterprise storage arrays.

CHFS is a file system developed at the Department of Software Engineering, University of Szeged, Hungary. It was the first open source flash memory-specific file system written for the NetBSD operating system. Intended usage is over raw flash devices on embedded systems like ARM and MIPS, the filesystem is less suitable for use on consumer SSD.

F2FS is a flash file system initially developed by Samsung Electronics for the Linux kernel.

Copyback is a NAND flash memory or SSD operation where data is read from one location in flash memory and written to another location, usually in the same LUN. This data does not need to be sent to the host as the copyback operation does not originate from a read request. Copybacks are closely related to write amplification.

An open-channel solid state drive is a solid-state drive which does not have a firmware Flash Translation Layer implemented on the device, but instead leaves the management of the physical solid-state storage to the computer's operating system. The Linux 4.4 kernel is an example of an operating system kernel that supports open-channel SSDs which follow the NVM Express specification. The interface used by the operating system to access open-channel solid state drives is called LightNVM.

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. 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 – 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.