From: Goffredo Baroncelli <kreijack@inwind.it>
To: ashford@whisperpc.com
Cc: Shriramana Sharma <samjnaa@gmail.com>,
Martin Steigerwald <martin@lichtvoll.de>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Why is the actual disk usage of btrfs considered unknowable?
Date: Mon, 08 Dec 2014 15:34:19 +0100 [thread overview]
Message-ID: <5485B6EB.1030101@inwind.it> (raw)
In-Reply-To: <73b1fa42cc61f5a843206a8164952f74.squirrel@webmail.wanet.net>
On 12/08/2014 01:12 AM, ashford@whisperpc.com wrote:
> Goffredo,
>
>> So in case you have a raid1 filesystem on two disks; each disk has 300GB
>> free; which is the free space that you expected: 300GB or 600GB and why ?
>
> You should see 300GB free. That's what you'll see with RAID-1 with a
> hardware RAID controller, and with MD RAID. Why would you expect to see
> anything else with BTRFS RAID?
I had to ask you because in a your previous email you stated something
different:
On 12/07/2014 09:32 PM, ashford@whisperpc.com wrote:
> I disagree. My experiences with other file-systems, including ZFS, show
> that the most common solution is to just deliver to the user the actual
> amount of *unused disk space*
^^^^^^^^^^^^^^^^^^^
So I expected that you answered with 600GB. But you have told the true:
the user want to know how many data is able to store on the disk, and
not the unused disk space.
But I have to point out that the common case is one disk filesystem
where the metadata chunks have a ratio data stored/disk space
consumed of 1:2; the data chunks have a ratio of 1:1. This is one
reason why is difficult to evaluate the free space: if you have
all metadata chunks, you have to half the disk space.
Another reason is that there is the idea to allow different raid
profiles in the same filesystem. This will further complicate the
free space evaluation.
> Peter Ashford
G.Baroncelli
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2014-12-08 14:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-07 15:15 Why is the actual disk usage of btrfs considered unknowable? Shriramana Sharma
2014-12-07 15:33 ` Martin Steigerwald
2014-12-07 15:37 ` Shriramana Sharma
2014-12-07 15:40 ` Martin Steigerwald
2014-12-08 5:32 ` Robert White
2014-12-08 6:20 ` ashford
2014-12-08 7:06 ` Robert White
2014-12-08 14:47 ` Martin Steigerwald
2014-12-08 14:57 ` Austin S Hemmelgarn
2014-12-08 15:52 ` Martin Steigerwald
2014-12-08 23:14 ` Zygo Blaxell
2014-12-07 18:20 ` ashford
2014-12-07 18:34 ` Hugo Mills
2014-12-07 18:48 ` Martin Steigerwald
2014-12-07 19:39 ` ashford
2014-12-08 5:17 ` Chris Murphy
2014-12-07 18:38 ` Martin Steigerwald
2014-12-07 19:44 ` ashford
2014-12-07 19:19 ` Goffredo Baroncelli
2014-12-07 20:32 ` ashford
2014-12-07 23:01 ` Goffredo Baroncelli
2014-12-08 0:12 ` ashford
2014-12-08 2:42 ` Qu Wenruo
2014-12-08 8:12 ` ashford
2014-12-08 14:34 ` Goffredo Baroncelli [this message]
2014-12-08 8:18 ` Chris Murphy
2014-12-08 4:59 ` Robert White
2014-12-08 6:43 ` Zygo Blaxell
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=5485B6EB.1030101@inwind.it \
--to=kreijack@inwind.it \
--cc=ashford@whisperpc.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=martin@lichtvoll.de \
--cc=samjnaa@gmail.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.