ext2_find_near(9)

📦 version 7.3.1, in nixpkgs unstable

✨ ext2_find_near(9) ✨

okay so bestie, this is a page straight out of the Kernel API Manual — it's ext2_find_near(9) and it's literally the matchmaker of ext2 block allocation 🎀

🌸 NAME 🌸

ext2_find_near — find a place for allocation with sufficient locality

(yes girl, it's out here finding blocks a good neighbourhood 🏡)

🦋 SYNOPSIS 🦋

ext2_fsblk_t ext2_find_near (struct inode *inode , Indirect *ind );

💅 ARGUMENTS 💅

  • inode — the owner. like, the inode that's gonna own this whole situation 👑
  • ind — descriptor of indirect block.

✨ DESCRIPTION ✨

So this function returns the preferred place for block allocation. Iconic behaviour, no cap. It gets called when the heuristic for sequential allocation fails — like, the usual plan didn't work out, so we gotta improvise 💀

The rules are, and I'm gonna say them exactly how they are:

  • if there is a block to the left of our position — allocate near it.
  • if pointer will live in indirect block — allocate near that block.
  • if pointer will live in inode — allocate in the same cylinder group.

In the latter case (the inode one, keep up 🫶) we colour the starting block by the callers PID to prevent it from clashing with concurrent allocations for a different inode in the same block group. The PID is used here so that functionally related files will be close-by on-disk. it's giving "keep your friends close" energy fr fr 🥺

⚠️ Caller must make sure that ind is valid and will stay that way. Like, genuinely. That's on you. Don't be out here passing a stale ind and then acting surprised 😭

🌈 SEE ALSO 🌈

Kernel file ./fs/ext2/inode.c — and the whole squad:

and that's the whole page bestie, we ate and left no crumbs 💅✨

sign-off time 🎀 this one lives in ./fs/ext2, dated October 2026 — go read it, ily, bye 💖

📦 where this page comes from