Notes on storage
A few documents I'm reading today. My goal is getting to know
the theory behind UBI (Unsorted Block Images).
Warning: the following is a list of bookmarks. The notes below
each link are relevant to me because they fill my gaps, and
because they act as a pesonal handbook: they are not meant as a a
summary of the page!
** Kernel.org / UBIFS
https://kernel.org/doc/html/v6.3-rc7/filesystems/ubifs.html
In regular MTD devices, read/write ops refer to some offset of an
erase block (variable, rather large size). By contrast, block
devices allow for 512-bytes read/write operations
UBI sits on the top of MTD, abstracts the wear leveling of erase
blocks and error detection.
https://en.wikipedia.org/wiki/Logical_block_addressing
Abstracts away the access detail of the hard drive. In "classic"
disks the addressing is defined by a CHS tuple (Cylinder, Head,
Sector).
With the advent os SCSI, Logical Block Addressing (LBA) was
introduced, abstracting away the accessing logic to the operating
system. Bad blocks became irrelevant: they are automatically
replaced under the hood.
** UBI **
http://www.linux-mtd.infradead.org/doc/ubi.html
LEB = Logical Erase Block
PEB = Physical Erase Block
Static volumes are read-only and use CRC-32 to detect errors,
whereas dynamic volumes assume a read-write FS to sit on the top
of them and do error detection.
Scrubbing: UBI transparently moves data away from worn PEBs.
Headers:
Each non-bad PEB contains EC and VID.
EC = Erase Count
VID = Volume IDentifier (the PEB belongs to a LEB in a volume)
UBI claims some space on the PEB to store EIC + VID + CRC(EIC +
VID) Attaching a MTD device to UBI requires a linear scan to
resume the metadata in RAM.
VID is undefined for unmapped PEBs, and is stored upon mapping
the PEB to a LEB. Subsequent writes do not touch metadata.
Erasure clears everything (including VID). It is always updated
after erasure: if not found (e.g. power loss between erase and
EIC write) it is estimated as the average of the whole MTD.
Volume table
A UBI device supports up to 128 volumes, each described by a
record in a special "layout volume". The layout volume itself
uses 2 LEB, corresponding to two copies, for fault tollerance.
The volume table info seems to correspond to the cfg file in
ubinize. TODO: verify if this is the case.
** Further things I'd like to learn more about: **
-
http://www.linux-mtd.infradead.org/doc/ubifs.html
- file system journaling
- FTL (Flash Translation Layer)
- SLC NAND flashes