bcachefs replica garbage collection

[Brian Foster <bfoster@redhat.com>]

Hi Kent,

I'm tracking an issue that seems to be related to bch_replica garbage
collection, where fsck reports the following:

  superblock not marked as containing replicas journal: 1/1 [1], not fixing

... and the fs doesn't want to mount (until repaired).

The short of it looks like there's a window where we write out the sb
replica info with no BCH_DATA_journal usage where a shutdown/recovery
doesn't otherwise expect it. I've not fully root caused the problem yet,
but when looking into the code it looks like we have a couple different
mechanisms for clearing out unused replicas...

The "old" _start/_end mechanism handles journal data only and is invoked
after pin flush. I presume the start/end calls wrap marking journal dev
replicas to ensure usage accounting is up to date, but I'm not totally
sure. Is that the case? If so, any reason the marking via
journal_write_done() isn't sufficient?

The "new" bch2_replicas_gc2() mechanism is invoked from various other
places and always propagates journal data replica entries. Is that
filter on journal data by design, or temporary because journal replica
gc is handled separately as above? If the latter, is there some explicit
reason the old mechanism was left around to handle journal data like
this?

As noted above, I still need to track down the root cause of the
unexpectedly absent journal data replica sb field. It may be agnostic to
either gc mechanism, but I'm trying to understand the higher level
situation here a bit better before getting too deep into the weeds...
thanks.

Brian