inode_go_inval(9)

💅 inode_go_inval 💅

okay so bestie, this is inode_go_inval from the Kernel API Manual — and it's giving “prepare the glock, we're wrapping up” energy. no cap, let's go 💖

🌸 NAME 🌸

inode_go_inval — prepare an inode glock to be released. like, get that glock ready to be let go 💅✨

🦋 SYNOPSIS 🦋

void inode_go_inval (struct gfs2_glock *gl , int flags );

🎀 ARGUMENTS 🎀

• gl — the glock 👑
• flags — the original page doesn't spell this one out, bestie, so I'm not gonna invent lore 🙈

✨ DESCRIPTION ✨

so normally? we invalidate everything — all of it, no crumbs 💀

but there's a little exception, and it's lowkey iconic: if we are moving into LM_ST_DEFERRED from LM_ST_SHARED or LM_ST_EXCLUSIVE, then we can keep hold of the metadata, since it won't have changed. periodt 🫶

bestie, that's the whole vibe: invalidation usually goes brrr, but that one state move gets to keep the metadata because it hasn't changed. 🧚

🌈 SEE ALSO 🌈

the Kernel file is ./fs/gfs2/glops.c, and the whole squad is:

• __gfs2_ail_flush(9)
• gfs2_rgrp_metasync(9)
• rgrp_go_sync(9)
• rgrp_go_inval(9)
• gfs2_inode_metasync(9)
• inode_go_sync(9)
• gfs2_inode_refresh(9)
• inode_go_instantiate(9)
• inode_go_dump(9)
• freeze_go_callback(9)
• freeze_go_xmote_bh(9)
• iopen_go_callback(9)

mwah 💋 sign-off time: source is ./fs/gfs2, the date line is October 2026, and the page is inode_go_inval(9) — catch u in the kernel docs, bestie 🫶💖🎀