mpage_readahead(9)

✨ mpage_readahead ✨

okay so bestie, welcome to the mpage_readahead(9) page from the Kernel API Manual — like, this is a real one from the kernel docs, and it's lowkey iconic once you get what it's doing 🫶

---

🌸 NAME 🌸

mpage_readahead — start reads against pages 💅

---

🎀 SYNOPSIS 🎀

void mpage_readahead (struct readahead_control *rac , get_block_t get_block );

---

🦋 ARGUMENTS 🦋

• rac — Describes which pages to read. Like, it's the vibe check for which pages we're pulling in 📄
• get_block — The filesystem's block mapper function. This is the glow-up translator that turns blocks into disk mappings 🔥

---

💖 DESCRIPTION 💖

So this function literally walks the pages and the blocks within each page, building and emitting large BIOs. Slay. It's giving bulk-I/O main character energy 👑

But — and hear me out — if anything unusual happens, such as:

• encountering a page which has buffers
• encountering a page which has a non-hole after a hole
• encountering a page with non-contiguous blocks

then this code just gives up and calls the buffer_head-based read function. No cap, it taps out 🙈 It does handle a page which has holes at the end — that's a common case, fr fr: the end-of-file on blocksize < PAGE_SIZE setups. So don't stress about that one ✨

💀 BH_Boundary explanation 💀

There is a problem. Not me being dramatic, there genuinely is 😭 The mpage read code assembles several pages, gets all their disk mappings, and then submits them all. That's fine, but obtaining the disk mappings may require I/O. Reads of indirect blocks, for example.

So an mpage read of the first 16 blocks of an ext2 file will cause I/O to be submitted in the following order:

12 0 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16

because the indirect block has to be read to get the mappings of blocks 13,14,15,16. Obviously, this impacts performance. Like, obviously 💀

So what we do is allow the filesystem's get_block function to set BH_Boundary when it maps block 11. BH_Boundary says: mapping of the block after this one will require I/O against a block which is probably close to this one. So you should push what I/O you have currently accumulated.

This all causes the disk requests to be issued in the correct order. Periodt. 🎯

---

🌈 SEE ALSO 🌈

Kernel file ./fs/mpage.c __mpage_writepages(9) 👀

---

and that's the whole page bestie, you ate that 🍓 this little gem is from the ./fs corner of the kernel tree, dated October 2026 — go forth and readahead responsibly 💜🧚