ext4_find_shared(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ‘‘ ext4_find_shared(9) β€” the Kernel API Manual, bestie edition ✨

okay so this one's from the Kernel API Manual and honestly? it's giving "backstage pass to the truncation crew" energy πŸŽ€


πŸ’– NAME πŸ’–

ext4_find_shared β€” literally just here to find the indirect blocks for partial truncation πŸ¦‹


✨ SYNOPSIS ✨

Indirect * ext4_find_shared (struct inode *inode , int depth ,
       ext4_lblk_t offsets[4] , Indirect chain[4] , __le32 *top );

like, that's the whole vibe. five args, one pointer back. no cap πŸ’…


🌸 ARGUMENTS 🌸

  • inode β€” the inode in question, aka the main character of this whole situation πŸ‘‘
  • depth β€” the depth of the affected branch. yes she has layers 🧚
  • offsets β€” the offsets of pointers in that branch (peep ext4_block_to_path if you need the lore) ⭐
  • chain β€” the place to store the pointers to partial indirect blocks. it's the storage unit bestie πŸŽ€
  • top β€” the place to the (detached) top of branch. note the word detached, that's important later πŸ™ˆ

πŸ”₯ DESCRIPTION πŸ”₯

so this is a helper function used by ext4_truncate. that's her job. that's what she does 🫢

here's the situation: when we do truncate we may have to clean the ends of several indirect blocks but leave the blocks themselves alive. block is partially truncated if some data below the new i_size is referred from it (and it is on the path to the first completely truncated data block, indeed). yeah. that's the definition, we don't make the rules πŸ’€

we have to free the top of that path along with everything to the right of the path. since no allocation past the truncation point is possible until ext4_truncate finishes, we may safely do the latter β€” but top of branch may require special attention, because pageout below the truncation point might try to populate it. so like, most of it is chill but that one bit? she needs watching πŸ‘€

ngl the top of the branch is the dramatic one. treat her accordingly.

so what happens is:

  • we atomically detach the top of branch from the tree πŸ”—
  • store the block number of its root in *top 🌟
  • pointers to buffer_heads of partially truncated blocks go in chain[].bh πŸ’«
  • pointers to their last elements that should not be removed go in chain[].p 🚫

the return value is the pointer to the last filled element of chain. iconic behaviour honestly 🎯

πŸ“ the work left to the caller πŸ“

the actual freeing of subtrees is not her problem, that's on you. specifically:

  1. free the subtree starting from *top
  2. free the subtrees whose roots are stored in (chain[i].p+1 .. end of chain[i].bh->b_data)
  3. free the subtrees growing from the inode past the chain[0]

like she did the detaching, you do the cleanup. teamwork fr fr 🫢


🌈 SEE ALSO 🌈

kernel file ./fs/ext4/indirect.c, plus the whole friend group:


and that's the whole page bestie πŸ’œ this one lives in ./fs/ext4 and the docs are dated October 2026 β€” screenshot it, cite it, slay it βœ¨πŸŽ€πŸŒŸ

πŸ“¦ where this page comes from