On Sun, Mar 03, 2024 at 08:02:47PM -0500, John Stoffel wrote: > >>>>> "Kent" == Kent Overstreet <kent.overstreet@xxxxxxxxx> 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.
