lnc_add(9)
π lnc_add β from the Kernel API Manual, bestie π
Okay so real talk, we're in lnc_add(9) today and it's literally the "add a leaf node to the leaf node cache" girlie. That's the whole vibe. Let's get into it β¨
πΈ SYNOPSIS πΈ
int lnc_add (struct ubifs_info *c , struct ubifs_zbranch *zbr , const
void *node );
Like, she takes three things and returns an int. Periodt.
π ARGUMENTS π
cβ the UBIFS file-system description object, your classic main-character context struct π«Άzbrβ the zbranch of the leaf node. yes. that one.nodeβ the leaf node itself, the whole point of the function ngl
π¦ DESCRIPTION π¦
So first things first: leaf nodes are the non-index nodes β either directory entry nodes or data nodes. That's the definition, no cap.
The purpose of the leaf node cache (LNC for the girlies in the know, iykyk) is to save re-reading the same leaf node over and over again π because doing that is giving wasted effort. Most things are cached by VFS, but β and this is the plot twist β the file system must cache directory entries for readdir and for resolving hash collisions. So LNC exists. Slay.
The present implementation of the leaf node cache is extremely simple, and it allows for error returns that are not used but that may be needed if a more complex implementation is created later. So like, the error returns are just sitting there being iconic and unemployed π but they're there for the future.
β οΈ Note bestie, this is important: this function does not add the node object to LNC directly. It allocates a copy of the object and adds the copy to LNC. Don't get it twisted π
The reason for that whole copy situation is that node has been allocated outside of the TNC subsystem and will be used with c->tnc_mutex unlock upon return from the TNC subsystem. But LNC may be changed at any time β e.g. freed by the shrinker. So yeah, the copy is protecting you. She's a bodyguard π§
π SEE ALSO π
Kernel file ./fs/ubifs/tnc.c plus this absolutely stacked friend group, fr fr:
insert_old_idx(9)insert_old_idx_znode(9)ins_clr_old_idx_znode(9)destroy_old_idx(9)copy_znode(9)add_idx_dirt(9)replace_znode(9)dirty_cow_znode(9)lnc_free(9)tnc_read_hashed_node(9)try_read_node(9)fallible_read_node(9)matches_name(9)get_znode(9)tnc_next(9)tnc_prev(9)resolve_collision(9)fallible_matches_name(9)fallible_resolve_collision(9)matches_position(9)resolve_collision_directly(9)dirty_cow_bottom_up(9)ubifs_lookup_level0(9)lookup_level0_dirty(9)maybe_leb_gced(9)ubifs_tnc_locate(9)ubifs_tnc_get_bu_keys(9)read_wbuf(9)validate_data_node(9)ubifs_tnc_bulk_read(9)do_lookup_nm(9)ubifs_tnc_lookup_nm(9)ubifs_tnc_lookup_dh(9)correct_parent_keys(9)insert_zbranch(9)tnc_insert(9)ubifs_tnc_add(9)ubifs_tnc_replace(9)ubifs_tnc_add_nm(9)tnc_delete(9)ubifs_tnc_remove(9)ubifs_tnc_remove_nm(9)ubifs_tnc_remove_dh(9)key_in_range(9)ubifs_tnc_remove_range(9)ubifs_tnc_remove_ino(9)ubifs_tnc_next_ent(9)tnc_destroy_cnext(9)ubifs_tnc_close(9)left_znode(9)right_znode(9)lookup_znode(9)is_idx_node_in_tnc(9)is_leaf_node_in_tnc(9)ubifs_tnc_has_node(9)ubifs_dirty_idx_node(9)dbg_check_inode_size(9)
Okay that's the whole page, bestie, you ate that π
β¨ This little gem comes to you from ./fs/ubifs, dated October 2026 β mwah, go read some more kernel docs, ily ππ
π¦ 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