ubifs_jnl_truncate(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ubifs_jnl_truncate(9) β€” like, the kernel API manual entry, bestie πŸŽ€

okay so this is ubifs_jnl_truncate, straight out of the Kernel API Manual bestie, and it's genuinely the moment a file gets shorter and the journal has to keep up ✨


🌸 NAME 🌸

ubifs_jnl_truncate β€” update the journal for a truncation.


πŸ¦‹ SYNOPSIS πŸ¦‹

int ubifs_jnl_truncate (struct ubifs_info *c , const struct inode *inode
, loff_t old_size , loff_t new_size );

πŸ’– ARGUMENTS πŸ’–

  • c β€” the UBIFS file-system description object. your whole file-system's main character, fr fr πŸ‘‘
  • inode β€” the inode to truncate. yeah. that one. βœ‚οΈ
  • old_size β€” old size. the before pic πŸ“Έ
  • new_size β€” new size. the after pic πŸ’…

✨ DESCRIPTION ✨

so when the size of a file decreases due to truncation, a truncation node is written, the journal tree is updated, and the last data block is re-written if it has been affected 😭 like the last data block literally gets dragged back into the group chat. the inode is also updated in order to synchronize the new inode size β€” nobody's walking around with a stale size, not on her watch 🫢

this function marks the inode as clean and returns zero on success. in case of failure, a negative error code is returned. periodt. πŸ’€

ngl bestie, success is 0 and failure is a negative error code β€” so like, don't go looking for a positive return value, it's not giving 🌈

πŸ”₯ SEE ALSO πŸ”₯

kernel file ./fs/ubifs/journal.c β€” and honestly the whole friend group shows up:


⭐ ok that's the whole page, no notes πŸ’œ this one's from ./fs/ubifs, dated October 2026, and it's literally titled ubifs_jnl_truncate(9) β€” iykyk, slay, bye bestie πŸ§šπŸ“

πŸ“¦ where this page comes from