ext4_find_shared(9)
π 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 (peepext4_block_to_pathif 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_headsof partially truncated blocks go inchain[].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:
- free the subtree starting from
*top - free the subtrees whose roots are stored in (
chain[i].p+1.. end ofchain[i].bh->b_data) - 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:
ext4_block_to_path(9)ext4_get_branch(9)ext4_find_near(9)ext4_find_goal(9)ext4_blks_to_allocate(9)ext4_alloc_branch(9)ext4_splice_branch(9)ext4_free_data(9)ext4_free_branches(9)ext4_ind_remove_space(9)
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
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms