From: Goffredo Baroncelli <kreijack@gmail.com>
To: "Hugo Mills" <hugo@carfax.org.uk>,
"Roman Mamedov" <rm@romanrm.ru>,
kreijack@libero.it, "Sébastien Maury" <sebastien.maury@inserm.fr>,
linux-btrfs@vger.kernel.org
Subject: Re: [RFC] btrfs fi df output [Was Re: BTRF - Storage Usage]
Date: Fri, 28 Sep 2012 19:27:16 +0200 [thread overview]
Message-ID: <5065DDF4.8010907@gmail.com> (raw)
In-Reply-To: <20120928085840.GE6136@carfax.org.uk>
Hi Hugo,
On 09/28/2012 10:58 AM, Hugo Mills wrote:
> On Fri, Sep 28, 2012 at 09:17:59AM +0600, Roman Mamedov wrote:
>> On Thu, 27 Sep 2012 23:02:35 +0200
>> Goffredo Baroncelli<kreijack@libero.it> wrote:
>>
[...]
> So that you can use, say, "read" in the shell to extract data from
> each line. To that end, there should be a space between the value and
> the unit throughout.
>
>>> Details:
>>> Chunk-type Mode Allocated Used Free
>>> ---------- ---- --------- -------- ---------
>
> Minor thing: The underlines are largely superfluous. Few basic CL
> tools I can think of use them.
Ok
>
>>> Data Single 4.01GB 2.16GB 1.87GB
>>> System DUP 16.00MB 4.00KB 7.99MB
>>> System Single 4.00MB 0.00 4.00MB
>>> Metadata DUP 6.00GB 429.16MB 2.57GB
>>> Metadata Single 8.00MB 0.00 8.00MB
>
> I think we need another column here, to indicate how much *actual*
> disk space is used by each row, so adding up that column will give you
> the "Allocated" value in the first clause. I think that's probably the
> biggest cause of confusion. "Raw alloc.", maybe, and use the term
> "raw" somewhere in the first clause to hammer the point home.
I think that there is a little misunderstanding. We are saying the same
thing. Only I call "allocated" what you call "raw alloc"
>
> My only concern here is that we're a bit too close to the existing
> solution (albeit merging the two sets of output), which has proven
> itself over time to be somewhat confusing. I think the Alloc_Raw
> column is the minimum necessary to link the two in some easily
> determinable way. Adding totals to Alloc_Raw, and Used (but not Free
> or Alloc) would help, I think. I don't think it's useful to add them
> to the Free or Alloc columns, because those figures change as the FS
> allocates chunks, and we'll end up with people querying the fact that
> the total of Free doesn't add up to any of the figures in the
> summary.
>
> Say, something like this:
>
> Summary_(Raw):
> Total: 135.00 GiB
> Allocated: 10.51 GiB
> Unallocated: 124.49 GiB
> Free_(Estimated): 86.56 GiB
> Average_disk_efficiency: 62 %
>
> Details:
> Chunk_type Mode Alloc_Raw Alloc Used Free
> Data Single 4.01 GiB 4.01 GiB 2.16 GiB 1.87 GiB
> System DUP 32.00 MiB 16.00 MiB 4.00 KiB 7.99 MiB
> System Single 4.00 MiB 4.00 MiB 0.00 B 4.00 MiB
> Metadata DUP 12.00 GiB 6.00 GiB 429.16 MiB 2.57 GiB
> Metadata Single 8.00 MiB 8.00 MiB 0.00 B 8.00 MiB
> Total 16.04 GiB 2.59 GiB
>
> The other thing is that there should be a switch (or possibly two)
> to give highly machine-readable versions of the output -- no units
> (units as bytes by default, with other units settable by a switch),
> tab-separated, possibly a different option for each of the above
> output clauses.
I fully Agree. But my first concern was about the wording (if fact even
though we are saying the same thing you didn't understood me).
Let me propose the following:
Summary:
Disk_size: 135.00 GiB
Disk_allocated: 10.51 GiB
Disk_unallocated: 124.49 GiB
Used: 2.59 GiB
Free_(Estimated): 91.93 GiB
Average_disk_efficiency: 70 %
Details:
Chunk-type Mode Disk-allocated Used Available
Data Single 4.01GB 2.16GB 1.87GB
System DUP 16.00MB 4.00KB 7.99MB
System Single 4.00MB 0.00 4.00MB
Metadata DUP 6.00GB 429.16MB 2.57GB
Metadata Single 8.00MB 0.00 8.00MB
Where:
Disk-allocated -> space used on the disk by the chunk
Disk-size -> size of the disk
Disk-unallocated -> disk not used in any chunk
Used -> space used by the files/metadata
Available -> space available in the *allocated* chunk
Free_(Estimated) -> Theoretical free space for files (Disk_size
* Average_disk_efficiency - Used)
>
> Ultimately, I think the bikeshed should be turquoise.
? :-)
>
> Hugo.
>
Ciao
Goffredo
next prev parent reply other threads:[~2012-09-28 17:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 10:44 BTRF - Storage Usage Sébastien Maury
2012-09-27 11:09 ` Hugo Mills
2012-09-27 11:25 ` Sébastien Maury
2012-09-27 11:43 ` Hugo Mills
2012-09-27 11:52 ` Sébastien Maury
2012-09-27 20:39 ` [RFC] btrfs fi df output [Was Re: BTRF - Storage Usage] Goffredo Baroncelli
2012-09-27 21:02 ` Goffredo Baroncelli
2012-09-28 3:17 ` Roman Mamedov
2012-09-28 8:58 ` Hugo Mills
2012-09-28 17:27 ` Goffredo Baroncelli [this message]
2012-09-28 20:13 ` Hugo Mills
2012-09-28 21:26 ` Goffredo Baroncelli
2012-09-29 7:19 ` Goffredo Baroncelli
2012-09-29 9:59 ` Sébastien Maury
2012-09-29 11:51 ` Goffredo Baroncelli
2012-11-12 18:16 ` Jan Engelhardt
2012-09-28 16:44 ` Goffredo Baroncelli
2012-09-28 18:02 ` Roman Mamedov
2012-09-28 19:38 ` Goffredo Baroncelli
2012-09-28 20:20 ` Hugo Mills
2012-09-28 21:26 ` Wade Cline
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=5065DDF4.8010907@gmail.com \
--to=kreijack@gmail.com \
--cc=hugo@carfax.org.uk \
--cc=kreijack@libero.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.ru \
--cc=sebastien.maury@inserm.fr \
/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.