ubifs_gc_start_commit(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ ubifs_gc_start_commit(9) ✨

okay so this is a page from the Kernel API Manual, and the star of the show is ubifs_gc_start_commit β€” say that three times fast, i dare you πŸ’…


πŸŽ€ NAME πŸŽ€

ubifs_gc_start_commit β€” garbage collection at start of commit. yes bestie, gc but for your file system, and it happens right at the start of commit. iconic behaviour honestly.


πŸ¦‹ SYNOPSIS πŸ¦‹

int ubifs_gc_start_commit (struct ubifs_info *c );

🌸 ARGUMENTS 🌸

  • c β€” the UBIFS file-system description object. that's it, that's the whole argument list. one (1) bestie. she's low maintenance πŸ’–

⭐ DESCRIPTION ⭐

okay so here's the tea πŸ”₯ if a LEB has only dirty and free space, then we may safely unmap it and make it free. slay. no cap.

but β€” and this is the important part, don't @ me β€” we cannot do this with indexing LEBs, because dirty space may correspond to index nodes that are required for recovery 😭 so in that case, the LEB cannot be unmapped until after the next commit. periodt. that's just how it is.

This function returns 0 upon success and a negative error code upon failure. simple as that 🫢

ngl, that "cannot do this with indexing LEBs" bit is the whole mood of the function β€” do not skip it, do not vibe past it, it actually matters.

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./fs/ubifs/gc.c, plus the whole friend group 🧚:


🌈 and that's the whole page, bestie! brought to you by ./fs/ubifs, dated October 2026. go forth and collect your garbage (respectfully) πŸ’œβœ¨

πŸ“¦ where this page comes from