linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.ru>
To: kreijack@inwind.it
Cc: kreijack@libero.it, "Sébastien Maury" <sebastien.maury@inserm.fr>,
	linux-btrfs@vger.kernel.org, "Hugo Mills" <hugo@carfax.org.uk>
Subject: Re: [RFC] btrfs fi df output [Was Re: BTRF - Storage Usage]
Date: Sat, 29 Sep 2012 00:02:23 +0600	[thread overview]
Message-ID: <20120929000223.4827d375@natsu> (raw)
In-Reply-To: <5065D3D7.8080101@inwind.it>

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

On Fri, 28 Sep 2012 18:44:07 +0200
Goffredo Baroncelli <kreijack@inwind.it> wrote:

> This means that the ration of space physically allocated on the disk and 
> the space available is 7GB/10GB = 0.7 . So on 135GB of disk, only 94GB 
> are available.

You assume metadata allocation will always grow linearly with data, which is
not true. So in my opinion it is not a good estimate.

> > Are you ready to answer the flood of questions from people why their disk is
> > only 62% efficient, and how to tune it to 100%? :-)
> 
> I don't understand your question

You mentioned that the aim was to make the output more friendly, i.e. to make
it less confusing. But I find this percentage and the way it is labeled likely
to achieve the opposite effect, causing a lot of new questions on what does
this mean (while the percentage reported is likely not even being correct),
how to improve it, etc.

> Because on BTRFS the metadata are a lot

Keep in mind that there is also inlining; so even if the space is allocated
for metadata, it will be used to store small files. So it might be not
completely fair to count the metadata allocated space as unusable space.

> > Why use underscores instead of spaces?
> 
> Simplify the parsing in scripts

I think it looks awkward and is not warranted since this is a primarily
user-facing utility. Also none of the other similar tools shy from having
spaces anywhere they need to, e.g.

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed May 25 00:07:38 2011
     Raid Level : raid5
     Array Size : 3907003136 (3726.01 GiB 4000.77 GB)
  Used Dev Size : 976750784 (931.50 GiB 1000.19 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Fri Sep 28 21:20:51 2012
          State : active 
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : avdeb:0  (local to host avdeb)
           UUID : b99961fb:ed1f76c8:ec2dad31:6db45332
         Events : 14254

    Number   Major   Minor   RaidDevice State
       7       8       17        0      active sync   /dev/sdb1
       6       8       33        1      active sync   /dev/sdc1
       3       8       65        2      active sync   /dev/sde1
       4       8       49        3      active sync   /dev/sdd1
       5       8       81        4      active sync   /dev/sdf1

# lvdisplay 
  --- Logical volume ---
  LV Path                /dev/alpha/lv1
  LV Name                lv1
  VG Name                alpha
  LV UUID                HP19fU-oMhM-sdqN-yFWa-N3Rs-ktBw-21GSD2
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 0
  LV Size                3.52 TiB
  Current LE             115431
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     4096
  Block device           252:0

-- 
With respect,
Roman

~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2012-09-28 18:02 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
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 [this message]
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=20120929000223.4827d375@natsu \
    --to=rm@romanrm.ru \
    --cc=hugo@carfax.org.uk \
    --cc=kreijack@inwind.it \
    --cc=kreijack@libero.it \
    --cc=linux-btrfs@vger.kernel.org \
    --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 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).