All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.