>>>>> "Kent" == Kent Overstreet <kent.overstreet@xxxxxxxxx> writes: > 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. 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.
