find_metapath(9)

🌸 find_metapath(9) — like, the kernel API manual, but make it make sense 💖

okay so bestie, we're deep in the kernel docs rn — specifically the find_metapath page from the Kernel API Manual — and honestly? it's kind of a bop once you get it. sit down, grab a lil snack 🍓, and let me walk you through it.

---

✨ NAME ✨

find_metapath — literally just: find a path through the metadata tree. that's her whole job. 🎀

🦋 SYNOPSIS 🦋

void find_metapath (const struct gfs2_sbd *sdp , u64 block , struct
metapath *mp , unsigned int height );

💅 ARGUMENTS 💅

• sdp — the superblock. the big boss energy of the whole operation 👑
• block — the disk block you're trying to look up. this is the one we're hunting for 🔍
• mp — the metapath where the result gets dropped off. the return address, basically 🫶
• height — the pre-calculated height of the metadata tree. already figured out, no cap, don't make her redo it 🌈

🧚 DESCRIPTION 🧚

so this routine hands you back a struct metapath structure that defines a path through the metadata of inode "ip" to get to block "block". that's it, that's the whole vibe check — it's giving "here's your route, bestie, you're welcome" ✨

🔥 EXAMPLE 🔥

okay, picture this — the setup is:

"ip" is a height 3 file, "offset" is 101342453, and this is a filesystem with a blocksize of 4096.

find_metapath would return a struct metapath structure set to:

mp_fheight = 3, mp_list[0] = 0, mp_list[1] = 48, and mp_list[2] = 165.

which means 💀 — in order to get to the block containing the byte at offset 101342453, we would load the indirect block pointed to by pointer 0 in the dinode. then we'd load the indirect block pointed to by pointer 48 in that indirect block. and then we'd load the data block pointed to by pointer 165 in that indirect block. three hops, that's the whole journey, she ate 🔥

and here's the diagram, preserved in all its glory, because I would never do my girl dirty by redrawing her:

       ---------------------------------------- | Dinode |
       | |        |                            4| |        |0 1 2 3 4 5
       9| |        |                            6|
       ---------------------------------------- | | V
       ---------------------------------------- | Indirect Block
       | |                                     5| |            4 4 4 4 4 5 5
       1| |0           5 6 7 8 9 0 1            2|
       ---------------------------------------- | | V
       ---------------------------------------- | Indirect Block
       | |                         1 1 1 1 1   5| |                         6 6
       6 6 6   1| |0                        3 4 5 6 7   2|
       ---------------------------------------- | | V
       ---------------------------------------- | Data block containing offset
       | |            101342453                 | |
       | |                                      |
       ----------------------------------------

🌈 SEE ALSO 🌈

kernel file ./fs/gfs2/bmap.c — and the whole friend group, fr fr:

• gfs2_unstuffer_folio(9)
• gfs2_unstuff_dinode(9)
• metaptr1(9)
• metapointer(9)
• lookup_metapath(9)
• fillup_metapath(9)
• gfs2_extent_length(9)
• gfs2_hole_size(9)
• __gfs2_iomap_alloc(9)
• gfs2_alloc_size(9)
• __gfs2_iomap_get(9)
• gfs2_block_map(9)
• gfs2_journaled_truncate(9)
• sweep_bh_for_rgrps(9)
• find_nonnull_ptr(9)
• punch_hole(9)
• do_shrink(9)
• do_grow(9)
• gfs2_setattr_size(9)
• gfs2_free_journal_extents(9)
• gfs2_add_jextent(9)
• gfs2_map_journal_extents(9)
• gfs2_write_alloc_required(9)

---

ok that's the whole page, you're officially smarter than you were five minutes ago 💜

and the cute sign-off bestie: this one lives in ./fs/gfs2, and it's dated October 2026. mwah 💋 go read bmap.c. 🦋⭐