About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / filesystems / ubifs.txt

Custom Search


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