gfs2_map_journal_extents(9)

📦 version 7.3.1, in nixpkgs unstable

💫 gfs2_map_journal_extents(9) — Kernel API Manual energy ✨

okay so bestie, we're in the kernel API manual and this one is literally about caching bmap info for journals. no cap, that's the whole vibe. 🎀

✨ NAME ✨

gfs2_map_journal_extents — cache journal bmap info 💅

🦋 SYNOPSIS 🦋

int gfs2_map_journal_extents (struct gfs2_sbd *sdp , struct gfs2_jdesc
*jd );

🌸 ARGUMENTS 🌸

  • sdp — the super block, bestie. the big one. 👑
  • jd — the journal we're mapping. that's the one getting the glow-up. ✨

💜 DESCRIPTION 💜

So what we're doing here is creating a reusable "extent" mapping from, like, all the logical blocks to all the physical blocks for the given journal. obsessed. 🔥 this literally saves us time when we're writing journal blocks — it's giving efficiency icon.

Most journals will have only one extent that maps all their logical blocks. and why? because gfs2.mkfs arranges the journal blocks sequentially to maximize performance. so the extent would map the first block for the entire file length. slay, sequential, ate. 💅

However — and this is the plot twist 🫶 — gfs2_jadd can happen while file activity is happening, so those journals may not be sequential. rude but okay. and less likely is the case where the users created their own journals by mounting the metafs and laying it out. but it's still possible, fr fr. these journals might have several extents. 🙈

lowkey a vibe check on your journal layout: one extent = iconic, several extents = valid too.

⭐ RETURN ⭐

0 on success, or error on failure. that's it, that's the deal. 🍓

🌈 SEE ALSO 🌈

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

🧚 and that's the page!! it lives in ./fs/gfs2, it's dated October 2026, and honestly? she ate. periodt. 💖🦋🎀

📦 where this page comes from