Re: [WIP] bcachefs fs usage update

["John Stoffel" <john@stoffel.org>]

>>>>> "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.