linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John Stoffel" <john@stoffel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: John Stoffel <john@stoffel.org>,
	linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [WIP] bcachefs fs usage update
Date: Sun, 3 Mar 2024 20:02:47 -0500	[thread overview]
Message-ID: <26085.7607.331602.673876@quad.stoffel.home> (raw)
In-Reply-To: <tis2cx7vpb2qyywdwq6a74o2ryjmnn7skhsrcarix7v4sz7vad@7sf7bh2unloo>

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

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*

John

  reply	other threads:[~2024-03-04  1:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-02  2:14 [WIP] bcachefs fs usage update Kent Overstreet
2024-03-03 18:49 ` John Stoffel
2024-03-03 23:19   ` Kent Overstreet
2024-03-04  1:02     ` John Stoffel [this message]
2024-03-04  1:08       ` Kent Overstreet
2024-03-04  8:16         ` Martin Steigerwald
     [not found]           ` <CAMT0RQRsdLd9dg5jkpQ+gRTn0XJe=cU5Umsjs2npyvz6pCU61g@mail.gmail.com>
2024-03-04 13:44             ` Hannu Krosing
2024-03-05  0:00         ` John Stoffel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26085.7607.331602.673876@quad.stoffel.home \
    --to=john@stoffel.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).