On 09/28/2012 08:02 PM, Roman Mamedov wrote:

On Fri, 28 Sep 2012 18:44:07 +0200
Goffredo Baroncelli[off-list ref]  wrote:

quoted

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.

I am open to accept suggestion on how improve the algorithm. Today we 
have only ... nothing. If I elaborate the output of btrfs fi show I can 
estimate the best-case (i.e. the data have no further redundancy); my 
algorithm is a bit smarter. However I repeat: please suggest us a better 
algorithm.

Regarding the assumption about the ratio data/metadata is constant, yes 
I assumed that. Why this should change ? Of course could change, but 
which would be a better estimation ?

My algorithm is not perfect, but better than nothing.

quoted

quoted

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.

These questions already are there, because the free space estimation in 
BTRFS is
a) very complex
b) "btrfs fi df" and "btrfs fi show" don't help to measure ( nor 
estimate) the space available.

quoted

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.

I never told that the metadata space is unusable space. Is true the 
opposite: I don't differentiate data/metadata/system.... I only consider 
the RAID/DUP/Single in terms of disk-space/available-space.

quoted

quoted

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.

We could improve on this side. However these utilities are often used in 
scripts

# 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