On Tue, Feb 27, 2024 at 10:49:19AM -0500, Brian Foster wrote:
> On Sat, Feb 24, 2024 at 09:38:03PM -0500, Kent Overstreet wrote:
> > New key type for the disk space accounting rewrite.
> >
> > - Holds a variable sized array of u64s (may be more than one for
> > accounting e.g. compressed and uncompressed size, or buckets and
> > sectors for a given data type)
> >
> > - Updates are deltas, not new versions of the key: this means updates
> > to accounting can happen via the btree write buffer, which we'll be
> > teaching to accumulate deltas.
> >
> > Signed-off-by: Kent Overstreet <[email protected]>
> > ---
> > fs/bcachefs/Makefile | 3 +-
> > fs/bcachefs/bcachefs.h | 1 +
> > fs/bcachefs/bcachefs_format.h | 80 +++------------
> > fs/bcachefs/bkey_methods.c | 1 +
> > fs/bcachefs/disk_accounting.c | 70 ++++++++++++++
> > fs/bcachefs/disk_accounting.h | 52 ++++++++++
> > fs/bcachefs/disk_accounting_format.h | 139 +++++++++++++++++++++++++++
> > fs/bcachefs/replicas_format.h | 21 ++++
> > fs/bcachefs/sb-downgrade.c | 12 ++-
> > fs/bcachefs/sb-errors_types.h | 3 +-
> > 10 files changed, 311 insertions(+), 71 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/replicas_format.h
> >
> ...
> > diff --git a/fs/bcachefs/disk_accounting_format.h
> > b/fs/bcachefs/disk_accounting_format.h
> > new file mode 100644
> > index 000000000000..e06a42f0d578
> > --- /dev/null
> > +++ b/fs/bcachefs/disk_accounting_format.h
> > @@ -0,0 +1,139 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _BCACHEFS_DISK_ACCOUNTING_FORMAT_H
> > +#define _BCACHEFS_DISK_ACCOUNTING_FORMAT_H
> > +
> > +#include "replicas_format.h"
> > +
> > +/*
> > + * Disk accounting - KEY_TYPE_accounting - on disk format:
> > + *
> > + * Here, the key has considerably more structure than a typical key
> > (bpos); an
> > + * accounting key is 'struct disk_accounting_key', which is a union of
> > bpos.
> > + *
>
> First impression.. I'm a little confused why the key type is a union of
> bpos. I'm possibly missing something fundamental/obvious, but could you
> elaborate more on why that is here?
How's this?
* More specifically: a key is just a muliword integer (where word endianness
* matches native byte order), so we're treating bpos as an opaque 20 byte
* integer and mapping bch_accounting_key to that.
