From: Ilya Dryomov <idryomov@gmail.com>
To: Goffredo Baroncelli <kreijack@gmail.com>
Cc: Chris Mason <chris.mason@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Goffredo Baroncelli <kreijack@inwind.it>
Subject: Re: [PATCH][BTRFS-PROGS][V1] btrfs filesystem df
Date: Wed, 3 Oct 2012 23:24:01 +0300 [thread overview]
Message-ID: <20121003202401.GC2890@zambezi.lan> (raw)
In-Reply-To: <506C997C.5070301@gmail.com>
On Wed, Oct 03, 2012 at 10:01:00PM +0200, Goffredo Baroncelli wrote:
> On 10/03/2012 07:46 PM, Ilya Dryomov wrote:
> >On Wed, Oct 03, 2012 at 06:46:00PM +0200, Goffredo Baroncelli wrote:
> >>On 10/03/2012 05:01 PM, Ilya Dryomov wrote:
> >>>"Type" for the first column is probably enough.
> >>>
> >>>Why is the third column called Chunk-size? If my understanding is
> >>>correct, it's just a break down of Disk_allocated from the summary
> >>>section. If so, why not call it Disk_allocated to avoid confusion?
> >>
> >>Using everywhere Disk_<something> was my first attempt. But after
> >>some thoughts I decided that these are two different kind of
> >>information. It is true that Disk_allocated is the sum of
> >>Chunk-Sizes... But my feels is that this is a kind of
> >>"implementation details". If some other type of allocation unit will
> >>be added to BTRFS, then these will be added to Disk_allocated, but
> >>not to Chunk list...
> >>I prefer to not change the wording until an enough critical mass of
> >>people converge to a unique solution .
> >
> >It is the chunks that is the implementation detail that we want to hide.
> >Average Btrfs user wouldn't want to know anything about chunks, the only
> >thing he'd be interested in is Disk_allocated and similar fields.
>
> The "df" standard tool id sufficient for the "average user".
> We need only to export these information via the standard syscall
> stat[v]fs. Basically we should try to implement the algorithm of the
> Free_(Estimated) space for the statfs(2) syscall.
> Who uses btrfs tools, is an user with knowledge of btrfs higher than
> the average.
>
> >Moreover, I am pretty sure "Chunk-Size" would actually confuse people.
> >I stared at your example output for a few seconds trying to comprehend a
> >21GB Chunk-Size on a 72GB partition. What you call "Chunk-Size" is
> >actually a sum of sizes of chunks of that particular type, and a few
> >lines above you call the same exact sum (only this time over all types
> >of chunks) "Disk_allocated". So I think it's only logical to rename the
> >column in question to "Disk_allocated" to match the summary section.
>
> What about
> [...]
> Details:
> Chunk_type Mode Size_(disk) Size_(logical) Used
> Data Single 21.01GB 21.01GB 10.53GB
> System DUP 80.00MB 40.00MB 4.00KB
> [...]
>
> ?
This is definitely better. Can you also drop "Chunk_type" in favor of
"Type"?
Thanks,
Ilya
next prev parent reply other threads:[~2012-10-03 20:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 11:43 [PATCH][BTRFS-PROGS][V1] btrfs filesystem df Goffredo Baroncelli
2012-10-03 11:43 ` [PATCH 1/2] Update btrfs filesystem df command Goffredo Baroncelli
2012-10-03 15:02 ` Ilya Dryomov
2012-10-03 16:34 ` Goffredo Baroncelli
2012-10-03 17:20 ` Ilya Dryomov
2012-10-03 17:38 ` Goffredo Baroncelli
2012-10-03 17:09 ` Goffredo Baroncelli
2012-10-03 11:43 ` [PATCH 2/2] Update help page Goffredo Baroncelli
2012-10-03 11:56 ` [PATCH][BTRFS-PROGS][V1] btrfs filesystem df Hugo Mills
2012-10-03 16:17 ` Goffredo Baroncelli
2012-10-03 16:34 ` Hugo Mills
2012-10-09 9:43 ` Bart Noordervliet
2012-10-09 11:38 ` Goffredo Baroncelli
2012-10-09 12:51 ` Bart Noordervliet
2012-10-09 18:22 ` Goffredo Baroncelli
2012-10-12 9:42 ` Martin Steigerwald
2012-10-03 15:01 ` Ilya Dryomov
2012-10-03 16:46 ` Goffredo Baroncelli
2012-10-03 17:46 ` Ilya Dryomov
2012-10-03 20:01 ` Goffredo Baroncelli
2012-10-03 20:24 ` Ilya Dryomov [this message]
2012-10-12 10:01 ` Martin Steigerwald
2012-10-12 9:55 ` Martin Steigerwald
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=20121003202401.GC2890@zambezi.lan \
--to=idryomov@gmail.com \
--cc=chris.mason@fusionio.com \
--cc=kreijack@gmail.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.