UBI File System

UBIFS와 플래시 장치의 기본 성질

UBIFS는 UBI File System의 약자이고, UBI는 "Unsorted Block Images"의 약자다. UBIFS는 플래시 장치용으로 설계된 플래시 파일 시스템이다. Ext2, XFS, JFS 같은 전통적인 Linux 파일 시스템은 블록 장치를 대상으로 하지만, UBIFS는 MTD 장치를 대상으로 하는 별도 계열의 파일 시스템이다. 이 계열의 다른 Linux 파일 시스템으로 JFFS2가 있다.

MTD 장치는 보통 약 128KiB인 비교적 큰 eraseblock으로 이루어지는 반면, 블록 장치는 보통 512바이트인 작은 블록으로 이루어진다. MTD가 제공하는 핵심 연산은 eraseblock 안의 오프셋에서 읽기, 오프셋에 쓰기, eraseblock 전체 지우기 세 가지다. 블록 장치의 핵심 연산은 블록 전체 읽기와 쓰기다.

플래시는 eraseblock의 내용을 다시 쓰기 전에 해당 eraseblock 전체를 지워야 한다. 또한 eraseblock에는 지우기 횟수에 따른 수명이 있다. 일반적으로 SLC NAND와 NOR 플래시는 약 10만~10억 회, MLC NAND 플래시는 약 1천~1만 회의 지우기 주기를 견딘다. NAND의 eraseblock은 불량 블록이 될 수도 있으므로 소프트웨어가 이를 처리해야 한다.

이에 비해 현대 LBA 디스크의 블록은 하드웨어가 불량 블록을 대체하는 장치를 갖추고 있어 보통 소프트웨어에 같은 성질을 드러내지 않는다. 지우기 선행 조건, 마모, 불량 eraseblock 때문에 UBIFS의 저장 모델은 전통적인 블록 파일 시스템과 근본적으로 다르다.

.. SPDX-License-Identifier: GPL-2.0

===============
UBI File System
===============

Introduction
============

UBIFS file-system stands for UBI File System. UBI stands for "Unsorted
Block Images". UBIFS is a flash file system, which means it is designed
to work with flash devices. It is important to understand, that UBIFS
is completely different to any traditional file-system in Linux, like
Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems
which work with MTD devices, not block devices. The other Linux
file-system of this class is JFFS2.

To make it more clear, here is a small comparison of MTD devices and
block devices.

1 MTD devices represent flash devices and they consist of eraseblocks of
  rather large size, typically about 128KiB. Block devices consist of
  small blocks, typically 512 bytes.
2 MTD devices support 3 main operations - read from some offset within an
  eraseblock, write to some offset within an eraseblock, and erase a whole
  eraseblock. Block  devices support 2 main operations - read a whole
  block and write a whole block.
3 The whole eraseblock has to be erased before it becomes possible to
  re-write its contents. Blocks may be just re-written.
4 Eraseblocks become worn out after some number of erase cycles -
  typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC
  NAND flashes. Blocks do not have the wear-out property.
5 Eraseblocks may become bad (only on NAND flashes) and software should
  deal with this. Blocks on hard drives typically do not become bad,
  because hardware has mechanisms to substitute bad blocks, at least in
  modern LBA disks.

It should be quite obvious why UBIFS is very different to traditional
file-systems.

UBI 계층과 JFFS2 대비

UBIFS는 UBI 위에서 동작한다. `drivers/mtd/ubi`에 있는 UBI는 볼륨 관리와 wear-leveling을 담당하는 별도 소프트웨어 계층이다. UBI가 제공하는 UBI volume은 MTD 장치보다 높은 수준의 추상화다.

UBI 장치의 프로그래밍 모델은 여전히 큰 eraseblock과 읽기·쓰기·지우기 연산을 사용하므로 MTD와 매우 비슷하다. 다만 UBI가 wear-leveling과 불량 블록 관리를 맡기 때문에, 상위의 UBIFS는 앞서 열거한 마모와 불량 블록 제약을 직접 처리하지 않아도 된다.

UBIFS는 어떤 의미에서는 JFFS2의 차세대 파일 시스템이지만, 구조가 매우 다르고 서로 호환되지 않는다. JFFS2는 MTD 장치 위에서 직접 동작하는 반면 UBIFS는 UBI에 의존해 UBI volume 위에서 동작한다.

JFFS2는 매체 내 인덱스가 없어 마운트할 때 전체 매체를 훑어 인덱스를 만들어야 한다. UBIFS는 파일 시스템 인덱스를 플래시 매체에 유지하므로 전체 스캔이 필요 없고 JFFS2보다 훨씬 빠르게 마운트된다. 또한 JFFS2는 write-through 파일 시스템이지만 UBIFS는 write-back을 지원해 쓰기 성능이 더 높다.

두 파일 시스템 모두 즉석 압축을 지원해 플래시에 더 많은 데이터를 저장할 수 있고, 비정상 재부팅과 전원 차단을 견딘다. UBIFS는 저널을 자동 재생하여 충돌에서 복구하고 on-flash 자료구조의 일관성을 보장하므로 `fsck.ext2` 같은 별도 도구가 필요하지 않다.

UBIFS 내부 자료구조는 대부분 트리이므로 자체적으로는 로그 규모로 확장된다. 따라서 마운트 시간과 메모리 소비가 JFFS2처럼 플래시 크기에 선형 비례하지 않는다. 그러나 UBIFS 아래의 UBI는 선형으로 확장되므로 UBI/UBIFS 스택 전체의 확장성은 선형이다. 그래도 전체 스택은 JFFS2보다 상당히 잘 확장된다.

문서 작성자들은 UBI와 같은 API를 제공하면서 로그 규모로 확장되는 UBI2를 개발할 수 있다고 본다. UBI2는 UBI와 바이너리 호환되지 않더라도 API가 같으므로 UBIFS 자체는 변경하지 않고 사용할 수 있다는 구상이다.

UBIFS works on top of UBI. UBI is a separate software layer which may be
found in drivers/mtd/ubi. UBI is basically a volume management and
wear-leveling layer. It provides so called UBI volumes which is a higher
level abstraction than a MTD device. The programming model of UBI devices
is very similar to MTD devices - they still consist of large eraseblocks,
they have read/write/erase operations, but UBI devices are devoid of
limitations like wear and bad blocks (items 4 and 5 in the above list).

In a sense, UBIFS is a next generation of JFFS2 file-system, but it is
very different and incompatible to JFFS2. The following are the main
differences.

* JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on
  top of UBI volumes.
* JFFS2 does not have on-media index and has to build it while mounting,
  which requires full media scan. UBIFS maintains the FS indexing
  information on the flash media and does not require full media scan,
  so it mounts many times faster than JFFS2.
* JFFS2 is a write-through file-system, while UBIFS supports write-back,
  which makes UBIFS much faster on writes.

Similarly to JFFS2, UBIFS supports on-the-fly compression which makes
it possible to fit quite a lot of data to the flash.

Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.
It does not need stuff like fsck.ext2. UBIFS automatically replays its
journal and recovers from crashes, ensuring that the on-flash data
structures are consistent.

UBIFS scales logarithmically (most of the data structures it uses are
trees), so the mount time and memory consumption do not linearly depend
on the flash size, like in case of JFFS2. This is because UBIFS
maintains the FS index on the flash media. However, UBIFS depends on
UBI, which scales linearly. So overall UBI/UBIFS stack scales linearly.
Nevertheless, UBI/UBIFS scales considerably better than JFFS2.

The authors of UBIFS believe, that it is possible to develop UBI2 which
would scale logarithmically as well. UBI2 would support the same API as UBI,
but it would be binary incompatible to UBI. So UBIFS would not need to be
changed to use UBI2

마운트 옵션

표에서 `(*)`는 기본값을 뜻한다. `bulk_read`는 순차 읽기가 더 빠른 플래시 매체의 특성을 활용하도록 한 번에 더 많이 읽는다. 기본값인 `no_bulk_read`는 bulk read를 수행하지 않는다.

기본값인 `no_chk_data_crc`는 읽기 성능을 높이기 위해 data node의 CRC 검사를 건너뛴다. 플래시 매체의 신뢰성이 매우 높을 때만 사용해야 하며, 이 옵션에서는 파일 내용 손상이 감지되지 않을 수 있다. `chk_data_crc`는 data node CRC 검사를 생략하지 않는다.

`compr=none`, `compr=lzo`, `compr=zlib`은 기본 압축기를 각각 `none`, `lzo`, `zlib`으로 덮어쓴다. 이 옵션은 마운트된 파일 시스템에서 사용할 압축 방식을 명시적으로 선택한다.

`auth_key=`는 파일 시스템 인증에 사용할 키를 지정하며, 이 옵션을 전달하면 인증이 필수가 된다. 지정한 키는 kernel keyring에 존재해야 하고 `logon` 형식이어야 한다. `auth_hash_name=`은 해싱과 HMAC 생성에 모두 사용할 해시 알고리즘을 지정하며 대표 값으로 `sha256`과 `sha512`가 있다.

Mount options
=============

(*) == default.

====================        =======================================================
bulk_read                read more in one go to take advantage of flash
                        media that read faster sequentially
no_bulk_read (*)        do not bulk-read
no_chk_data_crc (*)        skip checking of CRCs on data nodes in order to
                        improve read performance. Use this option only
                        if the flash media is highly reliable. The effect
                        of this option is that corruption of the contents
                        of a file can go unnoticed.
chk_data_crc                do not skip checking CRCs on data nodes
compr=none              override default compressor and set it to "none"
compr=lzo               override default compressor and set it to "lzo"
compr=zlib              override default compressor and set it to "zlib"
auth_key=                specify the key used for authenticating the filesystem.
                        Passing this option makes authentication mandatory.
                        The passed key must be present in the kernel keyring
                        and must be of type 'logon'
auth_hash_name=                The hash algorithm used for authentication. Used for
                        both hashing and for creating HMACs. Typical values
                        include "sha256" or "sha512"
====================        =======================================================

빠른 사용 방법

마운트할 UBI volume은 `ubiX_Y` 또는 `ubiX:NAME` 문법으로 지정한다. 여기서 `X`는 UBI 장치 번호, `Y`는 UBI volume 번호, `NAME`은 UBI volume 이름이다.

UBI 장치 0의 volume 0을 `/mnt/ubifs`에 마운트하려면 `$ mount -t ubifs ubi0_0 /mnt/ubifs`를 실행한다. 같은 장치에서 이름이 `rootfs`인 volume은 `$ mount -t ubifs ubi0:rootfs /mnt/ubifs`로 마운트한다.

부팅할 때 `mtd0`을 UBI에 연결하고 이름이 `rootfs`인 volume을 루트 파일 시스템으로 마운트하는 kernel boot arguments의 예는 `ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs`다. `ubi.mtd=0`은 MTD 장치를 UBI에 연결하고, `root=`는 UBI volume을 선택하며, `rootfstype=ubifs`는 루트 파일 시스템 형식을 지정한다.

Quick usage instructions
========================

The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax,
where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is
UBI volume name.

Mount volume 0 on UBI device 0 to /mnt/ubifs::

    $ mount -t ubifs ubi0_0 /mnt/ubifs

Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume
name)::

    $ mount -t ubifs ubi0:rootfs /mnt/ubifs

The following is an example of the kernel boot arguments to attach mtd0
to UBI and mount volume "rootfs":
ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs

참고 자료

UBIFS에 관한 추가 문서와 FAQ/HOWTO는 MTD 웹 사이트의 `http://www.linux-mtd.infradead.org/doc/ubifs.html` 및 `http://www.linux-mtd.infradead.org/faq/ubifs.html`에서 확인할 수 있다. 링크는 원문 그대로 보존했다.

References
==========

UBIFS documentation and FAQ/HOWTO at the MTD web site:

- http://www.linux-mtd.infradead.org/doc/ubifs.html
- http://www.linux-mtd.infradead.org/faq/ubifs.html