STRUCT UBIFS_BUDGET_REQ(9)

💅 struct ubifs_budget_req(9) — like, the budget requirements of an operation, bestie ✨

okay so this is a page straight out of the Kernel API Manual (the struct ubifs_budget_req(9) one, mwah), and it's literally all about one lil struct that tells the UBIFS budgeting girlies what an operation is gonna cost. no cap, it's giving "receipt before you order". let's get into it 🧚

---

🌸 NAME 🌸

struct ubifs_budget_req — budget requirements of an operation. that's it, that's the vibe 💖

---

✨ SYNOPSIS ✨

here's the struct in all its glory, copy-pasted exactly because bestie we do NOT be messing with the source:

struct ubifs_budget_req {
    unsigned int fast:1;
    unsigned int recalculate:1;
  #ifndef UBIFS_DEBUG;
    unsigned int new_page:1;
    unsigned int dirtied_page:1;
    unsigned int new_dent:1;
    unsigned int mod_dent:1;
    unsigned int new_ino:1;
    unsigned int new_ino_d:13;
    unsigned int dirtied_ino:4;
    unsigned int dirtied_ino_d:15;
  #else;
    unsigned int new_page;
    unsigned int dirtied_page;
    unsigned int new_dent;
    unsigned int mod_dent;
    unsigned int new_ino;
    unsigned int new_ino_d;
    unsigned int dirtied_ino;
    unsigned int dirtied_ino_d;
  #endif;
    int idx_growth;
    int data_growth;
    int dd_growth;
 };

notice how when UBIFS_DEBUG is on, all the bitfields lose their widths and become plain old unsigned ints? that's the debug build living its best un-cramped life, periodt 🌈

---

🎀 Members 🎀

every single one, in order, no skipping (iykyk):

• fast — non-zero if the budgeting should try to acquire budget quickly and should not try to call write-back. girl is in a HURRY 🏃‍♀️💨
• recalculate — non-zero if idx_growth, data_growth, and dd_growth fields have to be re-calculated. math class is back in session 🔥
• new_page — non-zero if the operation adds a new page
• dirtied_page — non-zero if the operation makes a page dirty (messy but make it fashion 💅)
• new_dent — non-zero if the operation adds a new directory entry
• mod_dent — non-zero if the operation removes or modifies an existing directory entry
• new_ino — non-zero if the operation adds a new inode
• new_ino_d — how much data newly created inode contains
• dirtied_ino — how many inodes the operation makes dirty
• dirtied_ino_d — how much data dirtied inode contains

and then — not me, the page itself — the whole crew comes back for an encore, so here they are again, exactly as listed 🙈:

• new_page — non-zero if the operation adds a new page
• dirtied_page — non-zero if the operation makes a page dirty
• new_dent — non-zero if the operation adds a new directory entry
• mod_dent — non-zero if the operation removes or modifies an existing directory entry
• new_ino — non-zero if the operation adds a new inode
• new_ino_d — how much data newly created inode contains
• dirtied_ino — how many inodes the operation makes dirty
• dirtied_ino_d — how much data dirtied inode contains

and finally the growth girlies, the main characters of the second half:

• idx_growth — how much the index will supposedly grow
• data_growth — how much new data the operation will supposedly add
• dd_growth — how much data that makes other data dirty the operation will supposedly add (say that five times fast 😭)

---

🦋 Description 🦋

okay so idx_growth, data_growth and dd_growth are not used in budget request. like, they're not input fields, bestie — plot twist. the budgeting subsystem caches index and data growth values there so it doesn't have to re-calculate them when the budget is released. it's basically a notes app for later 📝. BUT — and this is the iconic part — if idx_growth is -1, it gets calculated by the release function using the other fields. surprise homework 📚

an inode may contain 4KiB of data at max., thus the widths of new_ino_d is 13 bits, and dirtied_ino_d — 15, because up to 4 inodes may be made dirty by the re-name operation. yes that's the whole reason for the weird numbers, she's doing math-correct 💀✨

⚠️ heads up bestie: UBIFS aligns node lengths to 8-bytes boundary, so the requester has to make sure the amount of inode data which contribute to new_ino_d and dirtied_ino_d fields are aligned. don't skip this one, it's not a suggestion 🫶

---

🔥 SEE ALSO 🔥

Kernel file ./fs/ubifs/ubifs.h — and look at this whole friend group, they all have man pages too:

struct ubifs_old_idx(9), struct ubifs_scan_node(9), struct ubifs_scan_leb(9), struct ubifs_gced_idx_leb(9), struct ubifs_inode(9), struct ubifs_unclean_leb(9), struct ubifs_lprops(9), struct ubifs_lpt_lprops(9), struct ubifs_lp_stats(9), struct ubifs_cnode(9), struct ubifs_pnode(9), struct ubifs_nbranch(9), struct ubifs_nnode(9), struct ubifs_lpt_heap(9), struct ubifs_wbuf(9), struct ubifs_bud(9), struct ubifs_jhead(9), struct ubifs_zbranch(9), struct ubifs_znode(9), struct bu_info(9), struct ubifs_node_range(9), struct ubifs_compressor(9), struct ubifs_orphan(9), struct ubifs_mount_opts(9), struct ubifs_budg_info(9), struct ubifs_stats_info(9), struct ubifs_info(9), ubifs_check_hash(9), ubifs_check_hmac(9), ubifs_branch_hash(9), ubifs_copy_hash(9), ubifs_auth_node_sz(9)

---

and that's the page bestie!! 🫶 it lives in ./fs/ubifs, dated October 2026, and it's struct ubifs_budget_req(9) — go forth and budget your requests responsibly, queen 👑💖