[PATCH 0/5] bcachefs: journal stall fixes

[Brian Foster <bfoster@redhat.com>]

Hi Kent,

Here's a few patches related to the journal stall issue with
generic/333. Patch 1 is the prospective fix, patches 2-4 make some
smallish cleanups to the stuck checking, and patch 5 is just an RFC for
the idea I mentioned previously wrt using a timeout. It has some issues
described in the commit log, so I'm just including it here for reference
and discussion in the event it leads to any more interesting ideas. I
think the path it's currently leading down is probably a bit of overkill
for the time being.

I've pushed patches 1-4 to the CI this morning, so we'll see how that
goes. One thing that annoys me a bit about patch 1 is that the seq
zapping presumably puts all of the processed keys at the start of the
sorted list in the write buffer flush slowpath, which then means the
loop starts by walking through those already processed keys.

I was thinking about possibly using a sentinel seq value (i.e.
UINT64_MAX or some such) to land those keys at the end of the list, but
it wasn't clear to me if such a value exists or the entire u64 space are
valid seq numbers. Another idea is to count the total number of
processed && skipped keys in the fast path and just start at that index
in the slow path, but also wasn't necessarily convinced if this is
likely enough to be worth the extra code.

Anyways.. thoughts, reviews, flames appreciated.

Brian

Brian Foster (5):
  bcachefs: more aggressive fast path write buffer key flushing
  bcachefs: gracefully unwind journal res slowpath on shutdown
  bcachefs: refactor journal stuck checking into standalone helper
  bcachefs: drop unnecessary journal stuck check from space calculation
  RFC: bcachefs: use a timeout for the journal stuck condition

 fs/bcachefs/btree_write_buffer.c | 41 +++++++-------
 fs/bcachefs/journal.c            | 95 ++++++++++++++++++++++++--------
 fs/bcachefs/journal_reclaim.c    | 19 +------
 3 files changed, 95 insertions(+), 60 deletions(-)

-- 
2.39.2