All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: Roman Mamedov <rm@romanrm.ru>
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: Fri, 28 Sep 2012 18:44:07 +0200	[thread overview]
Message-ID: <5065D3D7.8080101@inwind.it> (raw)
In-Reply-To: <20120928091759.6d096016@natsu>

On 09/28/2012 05:17 AM, Roman Mamedov wrote:
> On Thu, 27 Sep 2012 23:02:35 +0200
> Goffredo Baroncelli<kreijack@libero.it>  wrote:
>
>> Sorry for the space error:
>> Below a more correct example
>>
>> $ btrfs filesystem disk-free /
>> Summary:
>>      Total:             	        135.00GB
>>      Allocated:             	 10.51GB
>>      Unallocated:            	124.49GB
>>      Free_(Estimated)              86.56GB
>>      Average_disk_efficiency:         62 %
>
> How do you estimate "Free" here? Sorry I didn't check the source code in git,
> but from the "Details" below nothing leads me to believe that this FS is
> doomed to only be able to usefully utilize only ~86GB of the partition, and not
> more.


The estimation is made on the basis of the real allocated space on the 
disk and the available space.

In the example we know that BTRFS allocate:
- 4GB	in Single mode (4GB available, 2.16GB used)
- 16MB  in DUP mode (so  16/2=8MB available, 4kb used)
- 4MB   in Single mode (4MB available)
- 6GB   in DUP mode (6/2=3GB available, 429MB used)
- 8MB   in Single mode (8MB available)


So BTRFS allocated on disk 4GB+16MB+4MB+6GB+8MB = ~10GB, but the space 
availabled (regarding these allocated chunks) is 4GB+8MB+4MB+3GB+8MB = ~7GB.

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.

Yes my previous 0.62 was wrong. The real ratio is 0.7.


> 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: by default BTRFS store all metadata 
DUP-ed, this means that on the disk the space allocated are 2 times the 
space required. Because on BTRFS the metadata are a lot, this means that 
BTRFS is not so efficiency as other file-systems. This is a well know fact.

If you want to use all the space with the maximum efficiency, you could 
format the filesystem with the options "-m single".


>
> Why use underscores instead of spaces?

Simplify the parsing in scripts


>
>>
>> Details:
>>      Chunk-type    Mode       Allocated        Used        Free
>>      ----------    ----       ---------    --------   ---------
>>      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
>


  parent reply	other threads:[~2012-09-28 16:44 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 [this message]
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=5065D3D7.8080101@inwind.it \
    --to=kreijack@inwind.it \
    --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.