ubifs_recover_size_accum(9)
β¨ ubifs_recover_size_accum β¨
okay so bestie, welcome to the glow-up of ubifs_recover_size_accum(9) β that's the kernel API manual page for this little UBIFS recovery helper π
literally the whole vibe is "accumulate inode sizes for recovery" and honestly? iconic.
πΈ SYNOPSIS πΈ
int ubifs_recover_size_accum (struct ubifs_info *c , union ubifs_key
*key , int deletion , loff_t new_size );
that's the whole signature, fr fr β copy it exactly, no cap π«Ά
π ARGUMENTS π
cβ the UBIFS file-system description object π like, the whole fs's little profile cardkeyβ the node key πdeletionβ this node is for a deletion ποΈ (yes queen, it's a deletion)new_sizeβ the inode size π
π¦ DESCRIPTION π¦
okay so this function has two purposes, and they're both lowkey doing the most for the integrity of your file system:
- to ensure there are no data nodes that fall outside the inode size π§
- to ensure there are no data nodes for inodes that do not exist π»
to accomplish those purposes, a rb-tree is constructed containing an entry for each inode number in the journal that has not been deleted, and recording the size from the inode node, the maximum size of any data node (also altered by truncations) and a flag indicating a inode number for which no inode node was present in the journal. π it's giving red-black tree main character energy, honestly
note that there is still the possibility that there are data nodes that have been committed that are beyond the inode size, however the only way to find them would be to scan the entire index. alternatively, some provision could be made to record the size of inodes at the start of commit, which would seem very cumbersome for a scenario that is quite unlikely and the only negative consequence of which is wasted space. π so likeβ¦ yeah. it's a tradeoff, bestie. wasted space is the worst-case, and that's it.
this functions returns 0 on success and a negative error code on failure. β¨ no cap, that's the whole return contract
π SEE ALSO π
kernel file ./fs/ubifs/recovery.c is the home base, and these are all the siblings you should also go stan:
is_empty(9)first_non_ff(9)get_master_node(9)write_rcvrd_mst_node(9)ubifs_recover_master_node(9)ubifs_write_rcvrd_mst_node(9)is_last_write(9)clean_buf(9)no_more_nodes(9)fix_unclean_leb(9)drop_last_group(9)drop_last_node(9)ubifs_recover_leb(9)get_cs_sqnum(9)ubifs_recover_log_leb(9)recover_head(9)ubifs_recover_inl_heads(9)clean_an_unclean_leb(9)ubifs_clean_lebs(9)grab_empty_leb(9)ubifs_rcvry_gc_commit(9)struct size_entry(9)add_ino(9)find_ino(9)remove_ino(9)ubifs_destroy_size_tree(9)fix_size_in_place(9)inode_fix_size(9)ubifs_recover_size(9)
okay that's the whole page, bestie β go forth and recover those sizes π β¨
cute sign-off time π: this one lives in ./fs/ubifs, dated October 2026, and yes those are literally the manual's own source and date, I'm not making it up π«Ά
π¦ 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