ubi_leb_unmap(9)

💅 ubi_leb_unmap — the Kernel API Manual page, bestie edition ✨

okay so we're talking about ubi_leb_unmap(9) today — say it with me, "you-bee-eye leb un-map" — and honestly? she's that girl. let's get into it 🎀

---

🌸 NAME 🌸

ubi_leb_unmap — un-map logical eraseblock. that's it, that's the whole vibe. one job. iconic behavior. 👑

---

✨ SYNOPSIS ✨

int ubi_leb_unmap (struct ubi_volume_desc *desc , int lnum );

like, yes, that's the whole signature. copy it exactly, don't @ me. 🫶

---

🦋 ARGUMENTS 🦋

• desc — volume descriptor. this is your ✨entry pass✨ to the volume, bestie.
• lnum — logical eraseblock number. literally just the number of the LEB you're about to un-map.

---

💖 DESCRIPTION 💖

so what does this function actually do? okay so — it un-maps logical eraseblock lnum and schedules the corresponding physical eraseblock for erasure, so that it will eventually be physically erased in background. and the way that this operation is much faster than the erase operation?? we love a speed queen. 🔥

but now, bestie, here comes the part where you listen. 🎧

Unlike erase, the un-map operation does not guarantee that the logical eraseblock will contain all 0xFF bytes when UBI is initialized again. for example, if several logical eraseblocks are un-mapped, and an unclean reboot happens after this, the logical eraseblocks will not necessarily be un-mapped again when this MTD device is attached. they may actually be mapped to the same physical eraseblocks again. so, this function has to be used with care. ⚠️ no cap.

in other words (yes, I'm saying it again, because this is the important bit 🧚): when un-mapping a logical eraseblock, UBI does not store any information about this on the flash media, it just marks the logical eraseblock as "un-mapped" in RAM. and if UBI is detached before the physical eraseblock is physically erased, it will be mapped again to the same logical eraseblock when the MTD device is attached again. like it literally forgets. 😭 memory of a goldfish fr fr.

---

🌈 the actual use-case (the main character moment)

the main and obvious use-case of this function is when the contents of a logical eraseblock has to be re-written. and in that case it is much more efficient to first un-map it, then write new data, rather than first erase it, then write new data. it's giving "work smarter not harder". 💅

but note — once new data has been written to the logical eraseblock, UBI guarantees that the old contents has gone forever. 🫶 in other words, if an unclean reboot happens after the logical eraseblock has been un-mapped and then written to, it will contain the last written data. slay. that's the guarantee. that's the whole point. ⭐

---

🍓 return values & errors

this function returns zero in case of success and a negative error code in case of failure. classic.

and ooh, here's an edge case 👀 — if the volume is damaged because of an interrupted update, this function just returns immediately with -EBADF code. no drama, no fuss, just -EBADF and out. 💀

---

👑 SEE ALSO 👑

okay these are the siblings, the whole friend group, keep them all:

kernel file ./drivers/mtd/ubi/kapi.c, ubi_do_get_device_info(9), ubi_get_device_info(9), ubi_do_get_volume_info(9), ubi_get_volume_info(9), ubi_open_volume(9), ubi_open_volume_nm(9), ubi_get_num_by_path(9), ubi_open_volume_path(9), ubi_close_volume(9), leb_read_sanity_check(9), ubi_leb_read(9), ubi_leb_read_sg(9), ubi_leb_write(9), ubi_leb_erase(9), ubi_leb_map(9), ubi_is_mapped(9), ubi_sync(9), ubi_register_volume_notifier(9), ubi_unregister_volume_notifier(9)

---

aaaand that's the page!! 💜 mwah. before you go, tiny little sign-off from the void: this one lives in ./drivers/mtd/ubi, dated October 2026, and it's ubi_leb_unmap(9) forever and always. bye bestie, go un-map responsibly 🧚✨🎀