[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: [WIP] bcachefs fs usage update
From:       Hannu Krosing <hannuk () google ! com>
Date:       2024-03-04 13:44:39
Message-ID: CAMT0RQQp5mdRpgJ9ae=YF1uiSr-xMHe1rAA3OnAVDnqh8Jc0HA () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]