[WIP] bcachefs fs usage update

[WIP] bcachefs fs usage update

[Kent Overstreet]

I'm currently updating the 'bcachefs fs usage' command for the disk
accounting rewrite, and looking for suggestions on any improements we
could make - ways to present the output that would be clearer and more
useful, possibly ideas on on new things to count...

I think a shorter form of the per-device section is in order, a table
with data type on the x axis and the device on the y axis; we also want
percentages.

The big thing I'm trying to figure out is how to present the snapshots
counters in a useful way.

Snapshot IDs form trees, where subvolumes correspond to leaf nodes in
snapshot trees and interior nodes represent data shared between multiple
subvolumes.

That means it's straightforward to print how much data each subvolumme
is using directly - look up the subvolume for a given snapshot ID, look
up the filesystem path of that subvolume - but I haven't come up with a
good way of presenting how data is shared; these trees can be
arbitrarily large.

Thoughts?

Filesystem: 77d3a40d-58b6-46c9-a4d2-e59c8681e152
Size:                       11.0 GiB
Used:                       4.96 GiB
Online reserved:                 0 B
Inodes:                            4

Persistent reservations:
2x                          5.00 MiB

Data type       Required/total  Durability    Devices
btree:          1/2             2             [vdb vdc]           14.0 MiB
btree:          1/2             2             [vdb vdd]           17.8 MiB
btree:          1/2             2             [vdc vdd]           14.3 MiB
user:           1/2             2             [vdb vdc]           1.64 GiB
user:           1/2             2             [vdb vdd]           1.63 GiB
user:           1/2             2             [vdc vdd]           1.64 GiB

Compression:      compressed    uncompressed     average extent size
lz4                 4.63 GiB        6.57 GiB                 112 KiB
incompressible       328 MiB         328 MiB                 113 KiB

Snapshots:
4294967295          4.91 GiB

Btrees:
extents             12.0 MiB
inodes               256 KiB
dirents              256 KiB
alloc               10.8 MiB
subvolumes           256 KiB
snapshots            256 KiB
lru                  256 KiB
freespace            256 KiB
need_discard         256 KiB
backpointers        20.5 MiB
bucket_gens          256 KiB
snapshot_trees       256 KiB
logged_ops           256 KiB
accounting           256 KiB

(no label) (device 0):           vdb              rw
                                data         buckets    fragmented
  free:                     2.27 GiB           18627
  sb:                       3.00 MiB              25       124 KiB
  journal:                  32.0 MiB             256
  btree:                    15.9 MiB             127
  user:                     1.64 GiB           13733      41.1 MiB
  cached:                        0 B               0
  parity:                        0 B               0
  stripe:                        0 B               0
  need_gc_gens:                  0 B               0
  need_discard:                  0 B               0
  capacity:                 4.00 GiB           32768

(no label) (device 1):           vdc              rw
                                data         buckets    fragmented
  free:                     2.28 GiB           18652
  sb:                       3.00 MiB              25       124 KiB
  journal:                  32.0 MiB             256
  btree:                    14.1 MiB             113
  user:                     1.64 GiB           13722      38.5 MiB
  cached:                        0 B               0
  parity:                        0 B               0
  stripe:                        0 B               0
  need_gc_gens:                  0 B               0
  need_discard:                  0 B               0
  capacity:                 4.00 GiB           32768

(no label) (device 2):           vdd              rw
                                data         buckets    fragmented
  free:                     2.28 GiB           18640
  sb:                       3.00 MiB              25       124 KiB
  journal:                  32.0 MiB             256
  btree:                    16.0 MiB             128
  user:                     1.64 GiB           13719      38.6 MiB
  cached:                        0 B               0
  parity:                        0 B               0
  stripe:                        0 B               0
  need_gc_gens:                  0 B               0
  need_discard:                  0 B               0
  capacity:                 4.00 GiB           32768

Re: [WIP] bcachefs fs usage update

[John Stoffel]

>>>>> "Kent" == Kent Overstreet <kent.overstreet@linux.dev> writes:

> I'm currently updating the 'bcachefs fs usage' command for the disk
> accounting rewrite, and looking for suggestions on any improements we
> could make - ways to present the output that would be clearer and more
> useful, possibly ideas on on new things to count...

I've been meaning to play with bcachefs but haven't found the
time... but as a long time IT admin with a concentration in storage
and such, I've got some opinions to share... :-)

> I think a shorter form of the per-device section is in order, a
> table with data type on the x axis and the device on the y axis; we
> also want percentages.

So how can we make it so that the output is all on one line per-volume
(or sub-volume) so that we can more easily parse the results for our
own use?  

Can there be a way to export the data in CSV or (shudder) JSON format?
Or to change the output format ourselves to only show the columns
we're interested in using "-o <format>" type of specifications?

> The big thing I'm trying to figure out is how to present the snapshots
> counters in a useful way.

Think of it in terms of what the end user cares about, which is how
much space is taken up (and would be free'd if the snapshot was
deleted).  And how that space relates to the overall volume.

I realize this is hard to do when you have dedupe, compression, etc
all in play.  But so many people like to run close to the limits, and
when they have to delete a snapshot to make space on the main volume,
giving them an indication of how much space they will save is good.

Now I realize that if you have five snapshots from oldest to newest:

    a.        400mb
    b.        10mb
    c.        1g
    d.        10g
    e.        1g

deleting snapshot d will not free space because snapshot e depends on
it.  So it might be enough to note this in the docs and the help of
the commands.  But if I delete snapshot e (the most recent one) I
should get back 1g pretty quickly, right? 

> Snapshot IDs form trees, where subvolumes correspond to leaf nodes
> in snapshot trees and interior nodes represent data shared between
> multiple subvolumes.

Ugh... so this is a surprise in some ways, but probably only shows my
ignorance of bcachefs.  If I have a sub-volume, and it's created after
snapshot "c" given above and mounted.  Does it now go into the
space used for snapshots "d" and "e"?  So if so, then there needs to
be a way to show this.  

> That means it's straightforward to print how much data each
> subvolumme is using directly - look up the subvolume for a given
> snapshot ID, look up the filesystem path of that subvolume - but I
> haven't come up with a good way of presenting how data is shared;
> these trees can be arbitrarily large.

Well, be default I'd show the data in human readable format (ideally
with a way to sort by snapshot size!) where each volume lists it's
snapshots and sub-volumes (can there be sub-sub-...-volumes?)
intermixed by age, so you can see how much is used.

> Thoughts?

I'd love to see some example outputs, but I could also get off my ass
and actually setup my own test volumes and play around and make
comments.

but my core arguement stands, which is to make the output be concise.
The examples below are kinda way too verbose and way too long.  If I'm
in a terminal window, trying to keep it to as few lines as possible if
nice.  

> Filesystem: 77d3a40d-58b6-46c9-a4d2-e59c8681e152
> Size:                       11.0 GiB
> Used:                       4.96 GiB
> Online reserved:                 0 B
> Inodes:                            4

Why can't this be:

      Filesystem        Size        Used        Reserved        Inodes
      xxxxx             11.0 Gib    4.96 Gib    0 B             4

> Persistent reservations:
> 2x                          5.00 MiB

What does this mean to the end user?  

> Data type       Required/total  Durability    Devices
> btree:          1/2             2             [vdb vdc]           14.0 MiB
> btree:          1/2             2             [vdb vdd]           17.8 MiB
> btree:          1/2             2             [vdc vdd]           14.3 MiB
> user:           1/2             2             [vdb vdc]           1.64 GiB
> user:           1/2             2             [vdb vdd]           1.63 GiB
> user:           1/2             2             [vdc vdd]           1.64 GiB

How is this usedful?  What does it tell me?  Why do I care about
durability?  Especially in a summary output?  

> Compression:      compressed    uncompressed     average extent size
> lz4                 4.63 GiB        6.57 GiB                 112 KiB
> incompressible       328 MiB         328 MiB                 113 KiB

These are useful, but maybe only the comp/uncomp values.  

> Snapshots:
> 4294967295          4.91 GiB

There should be a count of the number of snapshots this space is used
in. 

> Btrees:
> extents             12.0 MiB
> inodes               256 KiB
> dirents              256 KiB
> alloc               10.8 MiB
> subvolumes           256 KiB
> snapshots            256 KiB
> lru                  256 KiB
> freespace            256 KiB
> need_discard         256 KiB
> backpointers        20.5 MiB
> bucket_gens          256 KiB
> snapshot_trees       256 KiB
> logged_ops           256 KiB
> accounting           256 KiB

Again, how does this help the end user?  What can they do to even
change these values?  They're great for debugging and info on the
filesystem, but for an end user that's just so much garbage and don't
tell you what you need to know.

> (no label) (device 0):           vdb              rw
>                                 data         buckets    fragmented
>   free:                     2.27 GiB           18627
>   sb:                       3.00 MiB              25       124 KiB
>   journal:                  32.0 MiB             256
>   btree:                    15.9 MiB             127
>   user:                     1.64 GiB           13733      41.1 MiB
>   cached:                        0 B               0
>   parity:                        0 B               0
>   stripe:                        0 B               0
>   need_gc_gens:                  0 B               0
>   need_discard:                  0 B               0
>   capacity:                 4.00 GiB           32768

Again, just the first line might be usedful, but why would I care?
And it's a total pain to parse as well.  

> (no label) (device 1):           vdc              rw
>                                 data         buckets    fragmented
>   free:                     2.28 GiB           18652
>   sb:                       3.00 MiB              25       124 KiB
>   journal:                  32.0 MiB             256
>   btree:                    14.1 MiB             113
>   user:                     1.64 GiB           13722      38.5 MiB
>   cached:                        0 B               0
>   parity:                        0 B               0
>   stripe:                        0 B               0
>   need_gc_gens:                  0 B               0
>   need_discard:                  0 B               0
>   capacity:                 4.00 GiB           32768

> (no label) (device 2):           vdd              rw
>                                 data         buckets    fragmented
>   free:                     2.28 GiB           18640
>   sb:                       3.00 MiB              25       124 KiB
>   journal:                  32.0 MiB             256
>   btree:                    16.0 MiB             128
>   user:                     1.64 GiB           13719      38.6 MiB
>   cached:                        0 B               0
>   parity:                        0 B               0
>   stripe:                        0 B               0
>   need_gc_gens:                  0 B               0
>   need_discard:                  0 B               0
>   capacity:                 4.00 GiB           32768


How can you shrink this down to be much more terse and useful?
Something like:

        device  label      free      user       capacity
        vda     (none)     x         y          Z               
        vdb     "foo bar"  x1        y1         Z1
        vdb     "foo"      x2        y2         Z2

Re: [WIP] bcachefs fs usage update

[Kent Overstreet]

On Sun, Mar 03, 2024 at 01:49:00PM -0500, John Stoffel wrote:
> Again, how does this help the end user?  What can they do to even
> change these values?  They're great for debugging and info on the
> filesystem, but for an end user that's just so much garbage and don't
> tell you what you need to know.

This is a recurring theme for you; information that you don't
understand, you think we can just delete... while you also say that you
haven't even gotten off your ass and played around with it.

So: these tools aren't for the lazy, I'm not a believer in the Gnome 3
philosophy of "get rid of anything that's not for the lowest common
denominator".

Rather - these tools will be used by people interested in learning more
about what their computers are doing under the hood, and they will
definitely be used when there's something to debug; I am a big believer
in tools that educate the user about how the system works, and tools
that make debugging easier.

'df -h' already exists if that's the level of detail you want :)

Re: [WIP] bcachefs fs usage update

[John Stoffel]

>>>>> "Kent" == Kent Overstreet <kent.overstreet@linux.dev> writes:

> On Sun, Mar 03, 2024 at 01:49:00PM -0500, John Stoffel wrote:
>> Again, how does this help the end user?  What can they do to even
>> change these values?  They're great for debugging and info on the
>> filesystem, but for an end user that's just so much garbage and don't
>> tell you what you need to know.

> This is a recurring theme for you; information that you don't
> understand, you think we can just delete... while you also say that you
> haven't even gotten off your ass and played around with it.

Fair complaint.  But I'm also coming at this NOT from a filesystem
developer point of view, but from the Sysadmin view, which is
different.  

> So: these tools aren't for the lazy, I'm not a believer in the Gnome
> 3 philosophy of "get rid of anything that's not for the lowest
> common denominator".

Ok, I can see that, but I never was arguing for simple info, I was
also arguing for parseable information dumps, for futher tooling.  I'm
happy to write my own tools to parse this output if need be to give
_me_ what I find useful.  

But you edlided that part of my comments.  Fine.  

> Rather - these tools will be used by people interested in learning more
> about what their computers are doing under the hood, and they will
> definitely be used when there's something to debug; I am a big believer
> in tools that educate the user about how the system works, and tools
> that make debugging easier.

> 'df -h' already exists if that's the level of detail you want :)

Sure, but when it comes to bcachefs, and sub-volumes (I'm following
the discussion of statx and how to make sub-volumes distinct from
their parent volumes) will df -h from gnu's coreutils package know how
to display the extra useful information, like compression ratios,
dedupe, etc.  And how snapshots are related to each other in terms of
disk space usage.  

This is not the same level of detail needed by a filesystem developer,
and I _never_ said it was.  I'm looking for the inforation
needed/wanted by a SysAdmin when an end user comes whining about
needing more space.  And then being able to examine the system
holistically to give them an answer.  Which usually means "delete
something!"  *grin*

John

Re: [WIP] bcachefs fs usage update

[Kent Overstreet]

On Sun, Mar 03, 2024 at 08:02:47PM -0500, John Stoffel wrote:
> >>>>> "Kent" == Kent Overstreet <kent.overstreet@linux.dev> writes:
> 
> > On Sun, Mar 03, 2024 at 01:49:00PM -0500, John Stoffel wrote:
> >> Again, how does this help the end user?  What can they do to even
> >> change these values?  They're great for debugging and info on the
> >> filesystem, but for an end user that's just so much garbage and don't
> >> tell you what you need to know.
> 
> > This is a recurring theme for you; information that you don't
> > understand, you think we can just delete... while you also say that you
> > haven't even gotten off your ass and played around with it.
> 
> Fair complaint.  But I'm also coming at this NOT from a filesystem
> developer point of view, but from the Sysadmin view, which is
> different.  
> 
> > So: these tools aren't for the lazy, I'm not a believer in the Gnome
> > 3 philosophy of "get rid of anything that's not for the lowest
> > common denominator".
> 
> Ok, I can see that, but I never was arguing for simple info, I was
> also arguing for parseable information dumps, for futher tooling.  I'm
> happy to write my own tools to parse this output if need be to give
> _me_ what I find useful.  
> 
> But you edlided that part of my comments.  Fine.  
> 
> > Rather - these tools will be used by people interested in learning more
> > about what their computers are doing under the hood, and they will
> > definitely be used when there's something to debug; I am a big believer
> > in tools that educate the user about how the system works, and tools
> > that make debugging easier.
> 
> > 'df -h' already exists if that's the level of detail you want :)
> 
> Sure, but when it comes to bcachefs, and sub-volumes (I'm following
> the discussion of statx and how to make sub-volumes distinct from
> their parent volumes) will df -h from gnu's coreutils package know how
> to display the extra useful information, like compression ratios,
> dedupe, etc.  And how snapshots are related to each other in terms of
> disk space usage.  

Getting subvolumes plumbed all the way into df -h is not on my short
term radar. I _am_ looking at, possibly, standardizing some APIs for
walking subvolumes - so depending on how that goes, perhaps.

> This is not the same level of detail needed by a filesystem developer,
> and I _never_ said it was.  I'm looking for the inforation
> needed/wanted by a SysAdmin when an end user comes whining about
> needing more space.  And then being able to examine the system
> holistically to give them an answer.  Which usually means "delete
> something!"  *grin*

'bcachefs fs usage' needs to show _all_ disk accounting information
bcachefs has, because we need there to be one single tool that shows all
the information we have - that's this tool.

If we're collecting information, it needs to be available.

There will no doubt be switches and options for providing reduced forms,
but for now I'm mainly concerned with making sure all the information
that we have is there in a reasonably understandable way.

Re: [WIP] bcachefs fs usage update

[Martin Steigerwald]

Kent Overstreet - 04.03.24, 02:08:44 CET:
> > This is not the same level of detail needed by a filesystem developer,
> > and I _never_ said it was.  I'm looking for the inforation
> > needed/wanted by a SysAdmin when an end user comes whining about
> > needing more space.  And then being able to examine the system
> > holistically to give them an answer.  Which usually means "delete
> > something!"  *grin*
> 
> 'bcachefs fs usage' needs to show _all_ disk accounting information
> bcachefs has, because we need there to be one single tool that shows all
> the information we have - that's this tool.
> 
> If we're collecting information, it needs to be available.
> 
> There will no doubt be switches and options for providing reduced forms,
> but for now I'm mainly concerned with making sure all the information
> that we have is there in a reasonably understandable way.

From a sysadmin view I totally get what John is writing.

I know "btrfs filesystem usage" also shows a lot of information, but still 
with some learning it is quite understandable. At least I can explain it 
nicely enough in one of my Linux Performance Analysis & Tuning courses.

Commands like "lspci" do not show all the information by default. You need 
to add "-v" even several times to show it all.

So I am with you that it is good to have a tool that shows *all* the 
information. I am just not so sure whether showing *all* the information 
by default is wise.

No one was asking for the lowest common denominator. But there is a 
balance between information that is useful in daily usage of BCacheFS and 
information that is more aimed at debugging purposes and filesystem 
developers. That "df -hT" is not really enough to understand what is going 
on in a filesystem like BCacheFS and BTRFS is clear.

So what I'd argue for is a middle ground by default and adding more with 
"-v" or "--detail" or an option like that. In the end if I consider who 
will be wanting to use the information, my bet would be it would be over 
95% sysadmins and Linux users at home. It would be less, I bet way less 
than 5% Linux filesystem developers. And that's generous. So "what target 
audience are you aiming at?" is an important question as well.

What also improves the utility of the displayed information is explaining 
it. In a man page preferably.

If there then is also a way to retrieve the information as JSON for 
something like that… it makes monitoring the usage state by 3rd party 
tools easier.

Another approach would be something like "free -m" versus "cat /proc/
meminfo" and "cat /proc/vmstat". I.e. provide all the details via SysFS 
and a part of it by "bcachefs filesystem usage".

You indeed asked for feedback about "bcachefs fs usage". So there you have 
it. As usual do with it what you want. You can even outright dismiss it 
without even considering it. But then I wonder why you asked for feedback 
to begin with. See, John just did what you asked for: John gave feedback.

I planned to go into detail of your example output and tell you what I 
think about each part of what you propose and ask questions for deeper 
understanding. If you are open to at least consider the feedback, only 
consider, of course you can still decline everything and all of it after 
consideration, then I'd be willing to spend the time to do it.

Best,
-- 
Martin

Re: [WIP] bcachefs fs usage update

[Hannu Krosing]

Can we have an option to get the output in JSON format so that it can
then be processed by whatever is doing the monitoring ?

Cheers
Hannu


On Mon, Mar 4, 2024 at 2:37 PM Hannu Krosing <hannuk@google.com> wrote:
>
> Can we have an option to get the output in JSON format so that it can then be processed by whatever is doing the monitoring ?
>
> Cheers
> Hannu
>
> On Mon, Mar 4, 2024 at 9:22 AM Martin Steigerwald <martin@lichtvoll.de> wrote:
>>
>> Kent Overstreet - 04.03.24, 02:08:44 CET:
>> > > This is not the same level of detail needed by a filesystem developer,
>> > > and I _never_ said it was.  I'm looking for the inforation
>> > > needed/wanted by a SysAdmin when an end user comes whining about
>> > > needing more space.  And then being able to examine the system
>> > > holistically to give them an answer.  Which usually means "delete
>> > > something!"  *grin*
>> >
>> > 'bcachefs fs usage' needs to show _all_ disk accounting information
>> > bcachefs has, because we need there to be one single tool that shows all
>> > the information we have - that's this tool.
>> >
>> > If we're collecting information, it needs to be available.
>> >
>> > There will no doubt be switches and options for providing reduced forms,
>> > but for now I'm mainly concerned with making sure all the information
>> > that we have is there in a reasonably understandable way.
>>
>> From a sysadmin view I totally get what John is writing.
>>
>> I know "btrfs filesystem usage" also shows a lot of information, but still
>> with some learning it is quite understandable. At least I can explain it
>> nicely enough in one of my Linux Performance Analysis & Tuning courses.
>>
>> Commands like "lspci" do not show all the information by default. You need
>> to add "-v" even several times to show it all.
>>
>> So I am with you that it is good to have a tool that shows *all* the
>> information. I am just not so sure whether showing *all* the information
>> by default is wise.
>>
>> No one was asking for the lowest common denominator. But there is a
>> balance between information that is useful in daily usage of BCacheFS and
>> information that is more aimed at debugging purposes and filesystem
>> developers. That "df -hT" is not really enough to understand what is going
>> on in a filesystem like BCacheFS and BTRFS is clear.
>>
>> So what I'd argue for is a middle ground by default and adding more with
>> "-v" or "--detail" or an option like that. In the end if I consider who
>> will be wanting to use the information, my bet would be it would be over
>> 95% sysadmins and Linux users at home. It would be less, I bet way less
>> than 5% Linux filesystem developers. And that's generous. So "what target
>> audience are you aiming at?" is an important question as well.
>>
>> What also improves the utility of the displayed information is explaining
>> it. In a man page preferably.
>>
>> If there then is also a way to retrieve the information as JSON for
>> something like that… it makes monitoring the usage state by 3rd party
>> tools easier.
>>
>> Another approach would be something like "free -m" versus "cat /proc/
>> meminfo" and "cat /proc/vmstat". I.e. provide all the details via SysFS
>> and a part of it by "bcachefs filesystem usage".
>>
>> You indeed asked for feedback about "bcachefs fs usage". So there you have
>> it. As usual do with it what you want. You can even outright dismiss it
>> without even considering it. But then I wonder why you asked for feedback
>> to begin with. See, John just did what you asked for: John gave feedback.
>>
>> I planned to go into detail of your example output and tell you what I
>> think about each part of what you propose and ask questions for deeper
>> understanding. If you are open to at least consider the feedback, only
>> consider, of course you can still decline everything and all of it after
>> consideration, then I'd be willing to spend the time to do it.
>>
>> Best,
>> --
>> Martin
>>
>>
>>

Re: [WIP] bcachefs fs usage update

[John Stoffel]

>>>>> "Kent" == Kent Overstreet <kent.overstreet@linux.dev> writes:

> On Sun, Mar 03, 2024 at 08:02:47PM -0500, John Stoffel wrote:
>> >>>>> "Kent" == Kent Overstreet <kent.overstreet@linux.dev> writes:
>> 
>> > On Sun, Mar 03, 2024 at 01:49:00PM -0500, John Stoffel wrote:
>> >> Again, how does this help the end user?  What can they do to even
>> >> change these values?  They're great for debugging and info on the
>> >> filesystem, but for an end user that's just so much garbage and don't
>> >> tell you what you need to know.
>> 
>> > This is a recurring theme for you; information that you don't
>> > understand, you think we can just delete... while you also say that you
>> > haven't even gotten off your ass and played around with it.
>> 
>> Fair complaint.  But I'm also coming at this NOT from a filesystem
>> developer point of view, but from the Sysadmin view, which is
>> different.  
>> 
>> > So: these tools aren't for the lazy, I'm not a believer in the Gnome
>> > 3 philosophy of "get rid of anything that's not for the lowest
>> > common denominator".
>> 
>> Ok, I can see that, but I never was arguing for simple info, I was
>> also arguing for parseable information dumps, for futher tooling.  I'm
>> happy to write my own tools to parse this output if need be to give
>> _me_ what I find useful.  
>> 
>> But you edlided that part of my comments.  Fine.  
>> 
>> > Rather - these tools will be used by people interested in learning more
>> > about what their computers are doing under the hood, and they will
>> > definitely be used when there's something to debug; I am a big believer
>> > in tools that educate the user about how the system works, and tools
>> > that make debugging easier.
>> 
>> > 'df -h' already exists if that's the level of detail you want :)
>> 
>> Sure, but when it comes to bcachefs, and sub-volumes (I'm following
>> the discussion of statx and how to make sub-volumes distinct from
>> their parent volumes) will df -h from gnu's coreutils package know how
>> to display the extra useful information, like compression ratios,
>> dedupe, etc.  And how snapshots are related to each other in terms of
>> disk space usage.  

> Getting subvolumes plumbed all the way into df -h is not on my short
> term radar. I _am_ looking at, possibly, standardizing some APIs for
> walking subvolumes - so depending on how that goes, perhaps.

And that's fine.  Then maybe one answer is to have a 'bcachefs fs df'
command which does show data like I'm asking for, but the focus is
more on the end user, not the developer.  

>> This is not the same level of detail needed by a filesystem developer,
>> and I _never_ said it was.  I'm looking for the inforation
>> needed/wanted by a SysAdmin when an end user comes whining about
>> needing more space.  And then being able to examine the system
>> holistically to give them an answer.  Which usually means "delete
>> something!"  *grin*

> 'bcachefs fs usage' needs to show _all_ disk accounting information
> bcachefs has, because we need there to be one single tool that shows all
> the information we have - that's this tool.

Sure, but does it need to show all the information all the time?  

> If we're collecting information, it needs to be available.

Sure, but does it need to be shown by default?  

> There will no doubt be switches and options for providing reduced forms,
> but for now I'm mainly concerned with making sure all the information
> that we have is there in a reasonably understandable way.

That's an answer then.  So if I want less information, I have to step
up and generate a patch bundle to propose such changes.  

Whcih I know I won't get to any time soon since I've got other
commitements first, and I'm not a strong developer, I'm a long time
SysAdmin.