[00/21] bcachefs disk accounting rewrite

  here it is; the disk accounting rewrite I've been talking about since
forever.

git link:
https://evilpiepirate.org/git/bcachefs.git/log/?h=bcachefs-disk-accounting-rewrite

test dashboard (just rebased, results are regenerating as of this
writing but shouldn't be any regressions left):
https://evilpiepirate.org/~testdashboard/ci?branch=bcachefs-disk-accounting-rewrite

The old disk accounting scheme was fast, but had some limitations:

 - lack of scalability: it was based on percpu counters additionally
   sharded by outstanding journal buffer, and then just prior to journal
   write we'd roll up the counters and add them to the journal entry.

   But this meant that all counters were added to every journal write,
   which meant it'd never be able to support per-snapshot counters.

 - it was a pain to extend
   this was why, until now, we didn't have proper compressed accounting,
   and getting compression ratio required a full btree scan

In the new scheme:
 - every set of counters is a bkey, a key in a btree
   (BTREE_ID_accounting).

   this means they aren't pinned in the journal

 - the key has structure, and is extensible
   disk_accounting_key is a tagged union, and it's just union'd over
   bpos

 - counters are deltas, until flushed to the underlying btree

   this means counter updates are normal btree updates; the btree write
   buffer makes counter updates efficient.

Since reading counters from the btree would be expensive - it'd require
a write buffer flush to get up-to-date counters - we also maintain a
parallel set of accounting in memory, a bit like the old scheme but
without the per-journal-buffer sharding. The in memory accounters
indexed in an eytzinger tree by disk_accounting_key/bpos, with the
counters themselves being percpu u64s.

Reviewers: do a "is this adequately documented, can I find my way
around, do things make sense", not line-by-line "does this have bugs".

Compatibility: this is in no way compatible with the old disk accounting
on disk format, and it's not feasible to write out accounting in the old
format - that means we have to regenerate accounting when upgrading or
downgrading past this version.

That should work more or less seamlessly with the most recent compat
bits (bch_sb_field downgrade, so we can tell older versions what
recovery psases to run and what to fix); additionally, userspace fsck
now checks if the kernel bcachefs version better matches the on disk
version than itself and if so uses the kernle fsck implementation with
the OFFLINE_FSCK ioctl - so we shouldn't be bouncing back and forth
between versions if your tools and kernel don't match.

upgrade/downgrade still need a bit more testing, but transparently using
kernel fsck is well tested as of latest versions.

but: 6.7 users (& possibly 6.8) beware, the sb_downgrade section is in
6.7 but BCH_IOCTL_OFFLINE_FSCK is not, and backporting that doesn't look
likely given current -stable process fiasco.

merge ETA - this stuff may make the next merge window; I'd like to get
per-snapshot-id accounting done with it, that should be the biggest item
left.

Cheers,
Kent

Kent Overstreet (21):
  bcachefs: KEY_TYPE_accounting
  bcachefs: Accumulate accounting keys in journal replay
  bcachefs: btree write buffer knows how to accumulate bch_accounting
    keys
  bcachefs: Disk space accounting rewrite
  bcachefs: dev_usage updated by new accounting
  bcachefs: Kill bch2_fs_usage_initialize()
  bcachefs: Convert bch2_ioctl_fs_usage() to new accounting
  bcachefs: kill bch2_fs_usage_read()
  bcachefs: Kill writing old accounting to journal
  bcachefs: Delete journal-buf-sharded old style accounting
  bcachefs: Kill bch2_fs_usage_to_text()
  bcachefs: Kill fs_usage_online
  bcachefs: Kill replicas_journal_res
  bcachefs: Convert gc to new accounting
  bcachefs: Convert bch2_replicas_gc2() to new accounting
  bcachefs: bch2_verify_accounting_clean()
  bcachefs: Eytzinger accumulation for accounting keys
  bcachefs: bch_acct_compression
  bcachefs: Convert bch2_compression_stats_to_text() to new accounting
  bcachefs: bch2_fs_accounting_to_text()
  bcachefs: bch2_fs_usage_base_to_text()

 fs/bcachefs/Makefile                   |   3 +-
 fs/bcachefs/alloc_background.c         | 137 +++--
 fs/bcachefs/alloc_background.h         |   2 +
 fs/bcachefs/bcachefs.h                 |  22 +-
 fs/bcachefs/bcachefs_format.h          |  81 +--
 fs/bcachefs/bcachefs_ioctl.h           |   7 +-
 fs/bcachefs/bkey_methods.c             |   1 +
 fs/bcachefs/btree_gc.c                 | 259 ++++------
 fs/bcachefs/btree_iter.c               |   9 -
 fs/bcachefs/btree_journal_iter.c       |  23 +-
 fs/bcachefs/btree_journal_iter.h       |  15 +
 fs/bcachefs/btree_trans_commit.c       |  71 ++-
 fs/bcachefs/btree_types.h              |   1 -
 fs/bcachefs/btree_update.h             |  22 +-
 fs/bcachefs/btree_write_buffer.c       | 120 ++++-
 fs/bcachefs/btree_write_buffer.h       |  50 +-
 fs/bcachefs/btree_write_buffer_types.h |   2 +
 fs/bcachefs/buckets.c                  | 663 ++++---------------------
 fs/bcachefs/buckets.h                  |  70 +--
 fs/bcachefs/buckets_types.h            |  14 +-
 fs/bcachefs/chardev.c                  |  75 +--
 fs/bcachefs/disk_accounting.c          | 584 ++++++++++++++++++++++
 fs/bcachefs/disk_accounting.h          | 203 ++++++++
 fs/bcachefs/disk_accounting_format.h   | 145 ++++++
 fs/bcachefs/disk_accounting_types.h    |  20 +
 fs/bcachefs/ec.c                       | 166 ++++---
 fs/bcachefs/inode.c                    |  42 +-
 fs/bcachefs/journal_io.c               |  13 +-
 fs/bcachefs/recovery.c                 | 126 +++--
 fs/bcachefs/recovery_types.h           |   1 +
 fs/bcachefs/replicas.c                 | 242 ++-------
 fs/bcachefs/replicas.h                 |  16 +-
 fs/bcachefs/replicas_format.h          |  21 +
 fs/bcachefs/replicas_types.h           |  16 -
 fs/bcachefs/sb-clean.c                 |  62 ---
 fs/bcachefs/sb-downgrade.c             |  12 +-
 fs/bcachefs/sb-errors_types.h          |   4 +-
 fs/bcachefs/super.c                    |  74 ++-
 fs/bcachefs/sysfs.c                    | 109 ++--
 39 files changed, 1873 insertions(+), 1630 deletions(-)
 create mode 100644 fs/bcachefs/disk_accounting.c
 create mode 100644 fs/bcachefs/disk_accounting.h
 create mode 100644 fs/bcachefs/disk_accounting_format.h
 create mode 100644 fs/bcachefs/disk_accounting_types.h
 create mode 100644 fs/bcachefs/replicas_format.h
  

On Thu, Feb 29, 2024 at 04:16:00PM -0500, Kent Overstreet wrote:
> On Thu, Feb 29, 2024 at 01:44:27PM -0500, Brian Foster wrote:
> > On Wed, Feb 28, 2024 at 11:10:12PM -0500, Kent Overstreet wrote:
> > > I think it ended up not needing to be moved, and I just forgot to drop
> > > it - originally I disallowed accounting entries that referenced
> > > nonexistent devices, but that wasn't workable so now it's only nonzero
> > > accounting keys that aren't allowed to reference nonexistent devices.
> > > 
> > > I'll see if I can delete it.
> > > 
> > 
> > Do you mean to delete the change that moves the call, or the flush call
> > entirely?
> 
> Delte the change, I think there's further cleanup (& probably bugs to
> fix) possible with that flush call but I'm not going to get into it
> right now.
> 

Ok, just trying to determine whether I need to look back and make sure
this doesn't regress the problem this originally fixed.

> > > +/*
> > > + * Notes on disk accounting:
> > > + *
> > > + * We have two parallel sets of counters to be concerned with, and both must be
> > > + * kept in sync.
> > > + *
> > > + *  - Persistent/on disk accounting, stored in the accounting btree and updated
> > > + *    via btree write buffer updates that treat new accounting keys as deltas to
> > > + *    apply to existing values. But reading from a write buffer btree is
> > > + *    expensive, so we also have
> > > + *
> > 
> > I find the wording a little odd here, and I also think it would be
> > helpful to explain how/from where the deltas originate. For example,
> > something along the lines of:
> > 
> > "Persistent/on disk accounting, stored in the accounting btree and
> > updated via btree write buffer updates. Accounting updates are
> > represented as deltas that originate from <somewhere? trans triggers?>.
> > Accounting keys represent these deltas through commit into the write
> > buffer. The accounting/delta keys in the write buffer are then
> > accumulated into the appropriate accounting btree key at write buffer
> > flush time."
> 
> yeah, that's worth including.
> 
> There's an interesting point that you're touching on; btree write buffer
> are always dependent state changes from some other (non write buffer)
> btree; we never look at a write buffer btree and generate an update
> there - we can't, reading from a write buffer btree doesn't get you
> anything consistent or up to date.
> 
> So in normal operation it really only makes sense to do write buffer
> updates from a transactional trigger - that's the only way to use them
> and have them be consistent with the resst of the filesystem.
> 
> And since triggers work by comparing old and new, they naturally
> generate updates that are deltas.
> 

Hm that is interesting, I hadn't made that connection. Thanks.

Brian

> > > + *  - In memory accounting, where accounting is stored as an array of percpu
> > > + *    counters, indexed by an eytzinger array of disk acounting keys/bpos (which
> > > + *    are the same thing, excepting byte swabbing on big endian).
> > > + *
> > 
> > Not really sure about the keys vs. bpos thing, kind of related to my
> > comments on the earlier patch. It might be more clear to just elide the
> > implementation details here, i.e.:
> > 
> > "In memory accounting, where accounting is stored as an array of percpu
> > counters that are cheap to read, but not persistent. Updates to in
> > memory accounting are propagated from the transaction commit path."
> > 
> > ... but NBD, and feel free to reword, drop and/or correct any of that
> > text.
> 
> It's there because bch2_accounting_mem_read() takes a bpos when it
> should be a disk_accounting_key. I'll fix that if I can...
> 
> > > + *    Cheap to read, but non persistent.
> > > + *
> > > + * To do a disk accounting update:
> > > + * - initialize a disk_accounting_key, to specify which counter is being update
> > > + * - initialize counter deltas, as an array of 1-3 s64s
> > > + * - call bch2_disk_accounting_mod()
> > > + *
> > > + * This queues up the accounting update to be done at transaction commit time.
> > > + * Underneath, it's a normal btree write buffer update.
> > > + *
> > > + * The transaction commit path is responsible for propagating updates to the in
> > > + * memory counters, with bch2_accounting_mem_mod().
> > > + *
> > > + * The commit path also assigns every disk accounting update a unique version
> > > + * number, based on the journal sequence number and offset within that journal
> > > + * buffer; this is used by journal replay to determine which updates have been
> > > + * done.
> > > + *
> > > + * The transaction commit path also ensures that replicas entry accounting
> > > + * updates are properly marked in the superblock (so that we know whether we can
> > > + * mount without data being unavailable); it will update the superblock if
> > > + * bch2_accounting_mem_mod() tells it to.
> > 
> > I'm not really sure what this last paragraph is telling me, but granted
> > I've not got that far into the code yet either.
> 
> yeah that's for a whole different subsystem that happens to be slaved to
> the accounting - replicas.c, which also used to help out quite a bit
> with the accounting but now it's pretty much just for managing the
> superblock replicas section.
> 
> The superblock replicas section is just a list of entries, where each
> entry is a list of devices - "there is replicated data present on this
> set of devices". We also have full counters of how much data is present
> replicated across each set of devices, so the superblock section is just
> a truncated version of the accounting - "data exists on these devices",
> instead of saying how much.
>