Re: [WIP] bcachefs fs usage update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux