ubifs_garbage_collect(9)

📦 version 7.3.1, in nixpkgs unstable

💅✨ ubifs_garbage_collect(9) ✨💅

okay bestie, welcome to the Kernel API Manual page for ubifs_garbage_collect — the UBIFS garbage collector. she's giving out-of-place GC main character energy, and we're gonna get into it. 🗑️💖 no cap.

🌸 NAME 🌸

ubifs_garbage_collect — UBIFS garbage collector.

🌟 SYNOPSIS 🌟

int ubifs_garbage_collect (struct ubifs_info *c , int anyway );

🎀 ARGUMENTS 🎀

  • c — UBIFS file-system description object. yes, she's the whole file-system vibe. 🦋
  • anyway — do GC even if there are free LEBs. periodt.

🔥 DESCRIPTION 🔥

okay so this function literally does out-of-place garbage collection. vibe check on the return codes, because they're lowkey a whole mood:

  • a positive LEB number if the LEB has been freed and may be used
  • -EAGAIN if the caller has to run commit
  • -ENOSPC if GC failed to make any progress
  • other negative error codes in case of other errors

The garbage collector writes data to the journal when GC'ing data LEBs, and just marking indexing nodes dirty when GC'ing indexing LEBs. so yeah, at some point commit may be required. But commit cannot be run from inside GC, because the caller might be holding the commit lock — so -EAGAIN is returned instead. And this error code means that the caller has to run commit, and re-run GC if there is still no free space. 💅

There are many reasons why this function may return -EAGAIN:

  • the log is full and there is no space to write an LEB reference for c->gc_lnum
  • the journal is too large and exceeds size limitations
  • GC moved indexing LEBs, but they can be used only after the commit
  • the shrinker fails to find clean znodes to free and requests the commit
  • etc.
⚠️ Note, bestie: if the file-system is close to be full, this function may return -EAGAIN infinitely, so the caller has to limit amount of re-invocations of the function. E.g., this happens if the limits on the journal size are too tough and GC writes too much to the journal before an LEB is freed. This might also mean that the journal is too large, and the TNC becomes to big, so that the shrinker is constantly called, finds not clean znodes to free, and requests commit. Well, this may also happen if the journal is all right, but another kernel process consumes too much memory. ngl, infinite -EAGAIN may happen, but fr fr only in some extreme/misconfiguration cases.

🌈 SEE ALSO 🌈

Kernel file ./fs/ubifs/gc.c — go check her friends:

💌 source/version vibes: ./fs/ubifs, dated October 2026, page ubifs_garbage_collect(9) — okay that's the whole page, mwah, bye bestie! 🫶✨

📦 where this page comes from