^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) UBI File System
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) UBIFS file-system stands for UBI File System. UBI stands for "Unsorted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Block Images". UBIFS is a flash file system, which means it is designed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) to work with flash devices. It is important to understand, that UBIFS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) is completely different to any traditional file-system in Linux, like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) which work with MTD devices, not block devices. The other Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) file-system of this class is JFFS2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) To make it more clear, here is a small comparison of MTD devices and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) block devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) 1 MTD devices represent flash devices and they consist of eraseblocks of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) rather large size, typically about 128KiB. Block devices consist of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) small blocks, typically 512 bytes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) 2 MTD devices support 3 main operations - read from some offset within an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) eraseblock, write to some offset within an eraseblock, and erase a whole
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) eraseblock. Block devices support 2 main operations - read a whole
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) block and write a whole block.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) 3 The whole eraseblock has to be erased before it becomes possible to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) re-write its contents. Blocks may be just re-written.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 4 Eraseblocks become worn out after some number of erase cycles -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) NAND flashes. Blocks do not have the wear-out property.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) 5 Eraseblocks may become bad (only on NAND flashes) and software should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) deal with this. Blocks on hard drives typically do not become bad,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) because hardware has mechanisms to substitute bad blocks, at least in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) modern LBA disks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) It should be quite obvious why UBIFS is very different to traditional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) file-systems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) UBIFS works on top of UBI. UBI is a separate software layer which may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) found in drivers/mtd/ubi. UBI is basically a volume management and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) wear-leveling layer. It provides so called UBI volumes which is a higher
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) level abstraction than a MTD device. The programming model of UBI devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) is very similar to MTD devices - they still consist of large eraseblocks,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) they have read/write/erase operations, but UBI devices are devoid of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) limitations like wear and bad blocks (items 4 and 5 in the above list).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) In a sense, UBIFS is a next generation of JFFS2 file-system, but it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) very different and incompatible to JFFS2. The following are the main
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) differences.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) * JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) top of UBI volumes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) * JFFS2 does not have on-media index and has to build it while mounting,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) which requires full media scan. UBIFS maintains the FS indexing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) information on the flash media and does not require full media scan,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) so it mounts many times faster than JFFS2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) * JFFS2 is a write-through file-system, while UBIFS supports write-back,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) which makes UBIFS much faster on writes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Similarly to JFFS2, UBIFS supports on-the-flight compression which makes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) it possible to fit quite a lot of data to the flash.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) It does not need stuff like fsck.ext2. UBIFS automatically replays its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) journal and recovers from crashes, ensuring that the on-flash data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) structures are consistent.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) UBIFS scales logarithmically (most of the data structures it uses are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) trees), so the mount time and memory consumption do not linearly depend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) on the flash size, like in case of JFFS2. This is because UBIFS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) maintains the FS index on the flash media. However, UBIFS depends on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) UBI, which scales linearly. So overall UBI/UBIFS stack scales linearly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) Nevertheless, UBI/UBIFS scales considerably better than JFFS2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) The authors of UBIFS believe, that it is possible to develop UBI2 which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) would scale logarithmically as well. UBI2 would support the same API as UBI,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) but it would be binary incompatible to UBI. So UBIFS would not need to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) changed to use UBI2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Mount options
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) (*) == default.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) ==================== =======================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) bulk_read read more in one go to take advantage of flash
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) media that read faster sequentially
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) no_bulk_read (*) do not bulk-read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) no_chk_data_crc (*) skip checking of CRCs on data nodes in order to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) improve read performance. Use this option only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) if the flash media is highly reliable. The effect
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) of this option is that corruption of the contents
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) of a file can go unnoticed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) chk_data_crc do not skip checking CRCs on data nodes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) compr=none override default compressor and set it to "none"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) compr=lzo override default compressor and set it to "lzo"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) compr=zlib override default compressor and set it to "zlib"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) auth_key= specify the key used for authenticating the filesystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) Passing this option makes authentication mandatory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) The passed key must be present in the kernel keyring
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) and must be of type 'logon'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) auth_hash_name= The hash algorithm used for authentication. Used for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) both hashing and for creating HMACs. Typical values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) include "sha256" or "sha512"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) ==================== =======================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) Quick usage instructions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) UBI volume name.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) Mount volume 0 on UBI device 0 to /mnt/ubifs::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) $ mount -t ubifs ubi0_0 /mnt/ubifs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) name)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) $ mount -t ubifs ubi0:rootfs /mnt/ubifs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) The following is an example of the kernel boot arguments to attach mtd0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) to UBI and mount volume "rootfs":
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) References
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) UBIFS documentation and FAQ/HOWTO at the MTD web site:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) - http://www.linux-mtd.infradead.org/doc/ubifs.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) - http://www.linux-mtd.infradead.org/faq/ubifs.html
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags