jbd2_journal...free_buffers(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– jbd2_journal_try_to_free_buffers β€” kernel API manual, bestie edition πŸ’–

okay so this is a page from the Kernel API Manual, and it's about jbd2_journal_try_to_free_buffers. yes the name is long. yes it's lowkey a mouthful. no we are not skipping it. let's go 🫢


✨ NAME ✨

jbd2_journal_try_to_free_buffers β€” literally just trying to free page buffers. that's the whole vibe. πŸ’…


🌸 SYNOPSIS 🌸

bool jbd2_journal_try_to_free_buffers (journal_t *journal , struct folio
*folio );

copy it exactly, don't @ me, the spacing is what it is 😭


πŸŽ€ ARGUMENTS πŸŽ€

  • journal β€” the journal for the operation. it's the main character here, ngl πŸ‘‘
  • folio β€” the Folio we're detaching data from. bye bestie, data's leaving 🌈

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so here's the tea. for all the buffers on this page: if they're fully written out ordered data, we move them onto BUF_CLEAN so try_to_free_buffers can reap them. slay, clean buffers, iconic behavior ✨

This function returns non-zero if we wish try_to_free_buffers to be called. we do this if the page is releasable by try_to_free_buffers. we also do it if the page has locked or dirty buffers and the caller wants us to perform sync or async writeout. multitasking queen behavior fr fr πŸ‘‘

lowkey this complicates JBD locking somewhat. we aren't protected by the BKL here 🫣 we wish to remove the buffer from its committing or running transaction's ->t_datalist via __jbd2_journal_unfile_buffer.

This may change the value of transaction_t->t_datalist, so anyone who looks at t_datalist needs to lock against this function. yes literally anyone. the lock is not optional, no cap πŸ”’

Even worse β€” someone may be doing a jbd2_journal_dirty_data on this buffer. so we need to lock against that too. jbd2_journal_dirty_data will come out of the lock with the buffer dirty, which makes it ineligible for release here. it's giving ✨unavailable✨ πŸ’€

So who else is affected by this? hmm... πŸ€” really the only contender is do_get_write_access β€” it could be looking at the buffer while journal_try_to_free_buffer is changing its state. But that cannot happen because we never reallocate freed data as metadata while the data is part of a transaction. Yes? πŸ₯Ί (that "Yes?" is doing a lot of heavy lifting and it's in the original, so it stays, bestie πŸ’œ)

πŸ’€ return value vibe check: Return false on failure, true on success. that's it. that's the whole paragraph. periodt.

πŸ’€ SEE ALSO πŸ’€

Kernel file ./fs/jbd2/transaction.c β€” and honestly the whole friend group, gathered here for you:


πŸŽ€ that's the whole page, bestie! this one lives at ./fs/jbd2, dated October 2026, and it's part of the Kernel API Manual (jbd2_journal...free_buffers(9)). go forth and free those buffers responsibly πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from