__gfs2_iomap_alloc(9)

📦 version 7.3.1, in nixpkgs unstable

🌸 __gfs2_iomap_alloc(9) — the Kernel API Manual, bestie edition 🌸

okay so this page lives in the Kernel API Manual and it's literally all about building a metadata tree of the requested height 💅 like, you know when you need a tree and it needs to be a specific height? yeah. that. let's get into it 🫶

✨ NAME ✨

__gfs2_iomap_alloc — build a metadata tree of the requested height 🎀 lowkey the whole personality of this function ngl

🦋 SYNOPSIS 🦋

int __gfs2_iomap_alloc (struct inode *inode , struct iomap *iomap ,
       struct metapath *mp );

three args, one int back, no cap 💜

🌸 ARGUMENTS 🌸

  • inode — the GFS2 inode 💖 like, the inode. the main character, fr.
  • iomap — the iomap structure ✨ your classic iomap situation.
  • mp — the metapath 🧚 and bestie, it needs to already have the proper height information calculated. don't come in here with a half-baked metapath, it's giving unprepared 😭

👑 DESCRIPTION 👑

okay so in this routine we may have to alloc three whole vibes of thing, and yes you have to keep all three straight 🍓:

  1. indirect blocks to grow the metadata tree height 🌱
  2. indirect blocks to fill in the lower part of the metadata tree 🧱
  3. data blocks 💾

this function is called after __gfs2_iomap_get, which is the one that actually works out the total number of blocks we need via gfs2_alloc_size 🔥 so like, the math is already done by the time we show up. we're just here to execute.

then we do the actual allocation, asking for an extent at a time — and here's the slay part: if enough contiguous free blocks are available, there will only be one allocation request per call 😌✨ and then we use the state machine to initialise the blocks in order. state machine doing the heavy lifting, as always 💅

right now? this function will allocate at most one indirect block worth of data — with a default block size of 4K, that's slightly less than 2M 🙈 that's the cap, that's the limit, that's the vibe check result.

and if this limitation is ever removed to allow huge allocations, we would probably still want to limit the iomap size we return, to avoid stalling other tasks during huge writes 🫶 the next iomap iteration would then find the blocks already allocated. so like — even in the glowing future where we're huge? still limiting. periodt. 💀

🔥 RETURN 🔥

errno on error 😭 (that's it, that's the return section, we keep it real)

🌈 SEE ALSO 🌈

kernel file ./fs/gfs2/bmap.c plus the whole friend group 👑:

ok literally that's the whole page, go read bmap.c if you want the deep lore 🙈

and that's a wrap bestie 💖 this came from the source tree at ./fs/gfs2, dated October 2026, and the page itself is __gfs2_iomap_alloc(9) — mwah, go build some trees 🌈⭐🎀

📦 where this page comes from