STRUCT UBI_VTBL_RECORD(9)

💖 struct ubi_vtbl_record — a record in the volume table 💖

okay so bestie, this is a page from the Kernel API Manual about struct ubi_vtbl_record, and honestly? it's lowkey iconic. it's the little record that holds down the whole volume table. let's get into it ✨

---

🌸 SYNOPSIS 🌸

struct ubi_vtbl_record {
    __be32 reserved_pebs;
    __be32 alignment;
    __be32 data_pad;
    __u8 vol_type;
    __u8 upd_marker;
    __be16 name_len;
    __u8 name[UBI_VOL_NAME_MAX+1];
    __u8 flags;
    __u8 padding[23];
    __be32 crc;
 };

no cap, that's the whole shape of it. now let's meet the members one by one 🫶

---

🎀 Members 🎀

• reserved_pebs — how many physical eraseblocks are reserved for this volume. like, this volume's whole allocated situation 💅
• alignment — the volume alignment
• data_pad — how many bytes are unused at the end of the each physical eraseblock to satisfy the requested alignment
• vol_type — the volume type, which is either UBI_DYNAMIC_VOLUME or UBI_STATIC_VOLUME
• upd_marker — if volume update was started but not finished 👀 (we'll circle back to this one, it's kind of a big deal)
• name_len — volume name length
• name — the volume name
• flags — volume flags (UBI_VTBL_AUTORESIZE_FLG)
• padding — reserved, zeroes
• crc — a CRC32 checksum of the record

---

🦋 Description 🦋

so the volume table records are stored in the volume table, which is stored in the layout volume. and the layout volume consists of 2 logical eraseblock, each of which contains a copy of the volume table (i.e., the volume table is duplicated). yes bestie, it's giving redundancy, it's giving "we made a backup because we care". ✨

the volume table is an array of struct ubi_vtbl_record objects indexed by the volume ID. very demure, very indexed.

here's the size situation, pay attention: if the size of the logical eraseblock is large enough to fit UBI_MAX_VOLUMES records, the volume table contains UBI_MAX_VOLUMES records. otherwise, it contains as many records as it can fit (i.e., size of logical eraseblock divided by sizeof(struct ubi_vtbl_record)). math ate, honestly. 🔥

now the upd_marker flag — it's used to implement volume update. it is set to 1 before update and set to 0 after the update. so if the update operation was interrupted, UBI knows that the volume is corrupted. 😭 like, it literally leaves a little note for UBI saying "yeah we never finished". tragic but useful.

the alignment field is specified when the volume is created and cannot be later changed. periodt, it's locked in forever. it may be useful, for example, when a block-oriented file system works on top of UBI. the data_pad field is calculated using the logical eraseblock size and alignment. and the alignment must be multiple to the minimal flash I/O unit. if alignment is 1, all the available space of the physical eraseblocks is used. fyi, alignment of 1 is the "use everything, no crumbs left" vibe 🍓

also! empty records contain all zeroes and the CRC checksum of those zeroes. so an empty record is still a valid record, it's just a zeroes situation with a matching checksum 💀

---

💜 SEE ALSO 💜

go read the kernel file ./drivers/mtd/ubi/ubi-media.h, plus these absolute legends:

• struct ubi_ec_hdr(9)
• struct ubi_vid_hdr(9)
• struct ubi_fm_sb(9)
• struct ubi_fm_hdr(9)
• struct ubi_fm_scan_pool(9)
• struct ubi_fm_ec(9)
• struct ubi_fm_volhdr(9)
• struct ubi_fm_eba(9)

---

and that's the page, bestie 💅 huge shoutout to ./drivers/mtd/ubi for hosting this whole thing, dated October 2026 — mark your calendars, the struct ubi_vtbl_record(9) girlies are thriving 🎀✨🦋