From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: <kreijack@inwind.it>, Robert White <rwhite@pobox.com>
Cc: <lists@colorremedies.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: get more accurate output in fd command.
Date: Thu, 11 Dec 2014 16:28:20 +0800 [thread overview]
Message-ID: <548955A4.3010006@cn.fujitsu.com> (raw)
In-Reply-To: <5488901F.9090107@inwind.it>
On 12/11/2014 02:25 AM, Goffredo Baroncelli wrote:
> On 12/10/2014 11:53 AM, Robert White wrote:
>> On 12/09/2014 05:08 PM, Dongsheng Yang wrote:
>>> On 12/10/2014 02:47 AM, Goffredo Baroncelli wrote:
>>>> Hi Dongsheng On 12/09/2014 12:20 PM, Dongsheng Yang wrote:
>>>>> When function btrfs_statfs() calculate the tatol size of fs, it
>>>>> is calculating the total size of disks and then dividing it by
>>>>> a factor. But in some usecase, the result is not good to user.
>>>>>
>>>>> Example: # mkfs.btrfs -f /dev/vdf1 /dev/vdf2 -d raid1 # mount
>>>>> /dev/vdf1 /mnt # dd if=/dev/zero of=/mnt/zero bs=1M count=1000
>>>>> # df -h /mnt Filesystem Size Used Avail Use% Mounted on
>>>>> /dev/vdf1 3.0G 1018M 1.3G 45% /mnt
>>>>>
>>>>> # btrfs fi show /dev/vdf1 Label: none uuid:
>>>>> f85d93dc-81f4-445d-91e5-6a5cd9563294 Total devices 2 FS bytes
>>>>> used 1001.53MiB devid 1 size 2.00GiB used 1.85GiB path
>>>>> /dev/vdf1 devid 2 size 4.00GiB used 1.83GiB path /dev/vdf2
>>>>>
>>>>> a. df -h should report Size as 2GiB rather than as 3GiB.
>>>>> Because this is 2 device raid1, the limiting factor is devid 1
>>>>> @2GiB.
>>>> I agree
>> NOPE.
>>
>> The model you propose is too simple.
>>
>> While the data portion of the file system is set to RAID1 the
>> metadata portion of the filesystem is still set to the default of
>> DUP. As such it is impossible to guess how much space is "free" since
>> it is unknown how the space will be used before hand.
>
> Hi Robert,
>
> sorry but you are talking about a different problem.
> Yang is trying to solve a problem where it is impossible to fill
> all the disk space because some portion is not raid1 protected. So
> it is incorrect to report all space/2 as free space.
>
> Instead you are stating that *if* the metadata are stored as DUP (and
> is not this case, because the metadata are raid1, see below), it is possible
> to fill all the disk space.
>
> This is a complex problem. The fact that BTRFS allows different
> raid levels causes to be very difficult to evaluate the free space (
> as space available directly to the user). There is no a simple answer.
>
> I am still convinced that the best free space *estimation* is considering
> the ratio disk-space-consumed/file-allocated constant, and evaluate
> the free space as the
>
> disk-space-unused*file-allocate/disk-space-consumed.
>
> Of course there are pathological cases that make this
> prediction fails completely. But I consider the best estimation
> possible for the average users.
>
> But again this is a different problem that the one raised by
> Yang.
Thanx Goffredo, I have cooked a v2 for this problem. I will send it out
soon.
>
>
>
> [...]
>
>> IF you wanted everything to be RAID-1 you should have instead done
>> # mkfs.btrfs -f /dev/vdf1 /dev/vdf2 -d raid1 -m raid1
>>
>> The mistake is yours, rest of you analysis is, therefore, completely
>> inapplicable. Please read all the documentation before making that
>> sort of filesystem. Your data will thank you later.
>>
>> DSCLAIMER: I have _not_ looked at the numbers you would get if you
>> used the corrected command.
> Sorry, but you are wrong. Doing mkfs.btrfs -d raid1 /dev/loop[01] leads
> to have both data and metadata in raid1. IIRC if you have more than
> one disks, the metadata switched to raid1 automatically.
>
> $ sudo mkfs.btrfs -d raid1 /dev/loop[01]
> Btrfs v3.17
> See http://btrfs.wiki.kernel.org for more information.
>
> Performing full device TRIM (10.00GiB) ...
> Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
> Performing full device TRIM (30.00GiB) ...
> adding device /dev/loop1 id 2
> fs created label (null) on /dev/loop0
> nodesize 16384 leafsize 16384 sectorsize 4096 size 40.00GiB
> ghigo@venice:/tmp$ sudo mount /dev/loop0 t/
> ghigo@venice:/tmp$ sudo dd if=/dev/zero of=t/fill bs=4M count=10
> 10+0 records in
> 10+0 records out
> 41943040 bytes (42 MB) copied, 0.018853 s, 2.2 GB/s
> ghigo@venice:/tmp$ sync
> ghigo@venice:/tmp$ sudo btrfs fi df t/
> Data, RAID1: total=1.00GiB, used=40.50MiB
> Data, single: total=8.00MiB, used=0.00B
> System, RAID1: total=8.00MiB, used=16.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, RAID1: total=1.00GiB, used=160.00KiB
> Metadata, single: total=8.00MiB, used=0.00B
> GlobalReserve, single: total=16.00MiB, used=0.00B
>
> [...]
>
next prev parent reply other threads:[~2014-12-11 8:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 2:19 [bug] df reports wrong Size and Avail on raid1, 3.18rc2 Chris Murphy
2014-10-29 2:26 ` Eric Sandeen
2014-12-09 11:20 ` [PATCH] Btrfs: get more accurate output in fd command Dongsheng Yang
2014-12-09 18:47 ` Goffredo Baroncelli
2014-12-10 1:08 ` Dongsheng Yang
2014-12-10 10:53 ` Robert White
2014-12-10 13:21 ` Duncan
2014-12-10 15:02 ` Dongsheng Yang
2014-12-10 19:05 ` Goffredo Baroncelli
2014-12-11 8:23 ` Dongsheng Yang
2014-12-11 3:53 ` Duncan
2014-12-11 8:25 ` Dongsheng Yang
2014-12-10 20:36 ` Robert White
2014-12-10 21:03 ` Goffredo Baroncelli
2014-12-10 14:51 ` Dongsheng Yang
2014-12-10 18:25 ` Goffredo Baroncelli
2014-12-11 8:28 ` Dongsheng Yang [this message]
2014-12-10 13:59 ` Shriramana Sharma
2014-12-10 14:56 ` Dongsheng Yang
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=548955A4.3010006@cn.fujitsu.com \
--to=yangds.fnst@cn.fujitsu.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=rwhite@pobox.com \
/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.