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@xxxxxxxxxx> 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@xxxxxxxxxxxx> 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 >> >> >>
