gfs2_read_super(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– gfs2_read_super(9) β€” kernel API manual energy ✨

okay so bestie, we're in the Kernel API Manual today and the main character is gfs2_read_super(9). buckle up πŸŽ€


🌸 NAME 🌸

gfs2_read_super β€” read the gfs2 super block from disk. that's it, that's the vibe πŸ¦‹


✨ SYNOPSIS ✨

int gfs2_read_super (struct gfs2_sbd *sdp , sector_t sector , int silent
);

🫢 ARGUMENTS 🫢

  • sdp β€” the GFS2 super block. your fave struct, the whole point πŸ’…
  • sector β€” the location of the super block. where it lives on disk, iykyk
  • silent β€” don't print a message if the check fails. quiet queen behaviour 🀫

πŸ’œ DESCRIPTION πŸ’œ

so like. this uses the bio functions to read the super block from disk, and the reason is honestly so valid β€” we want to be 100% sure that we never read cached data. no cap, not even a little bit of cached data. πŸ™ˆ

here's the tea on when a super block gets read: it's read twice only during each GFS2 mount, and it is never written to by the filesystem. literally never. πŸ’€

the first time it's read, no locks are held, and the only details that get looked at are the ones relating to the locking protocol. once locking is up and working, the sb is read again under the lock to establish the location of:

  • the master directory (contains pointers to journals etc)
  • the root directory πŸ‘‘

πŸ”₯ RETURN πŸ”₯

0 on success or error. slay ✨


🌈 SEE ALSO 🌈


this one's brought to you by ./fs/gfs2, October 2026 edition, and the whole gfs2_read_super(9) moment. ily, go read your super blocks responsibly πŸ’–πŸ§šβ­
πŸ“¦ where this page comes from