From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: "not enough space" with "data raid0"
Date: Thu, 29 Mar 2012 01:07:05 +0000 (UTC) [thread overview]
Message-ID: <pan.2012.03.29.01.07.05@cox.net> (raw)
In-Reply-To: loom.20120329T000904-903@post.gmane.org
Alex posted on Wed, 28 Mar 2012 22:11:01 +0000 as excerpted:
> Phillip Susi <psusi <at> ubuntu.com> writes:
>
>
>> So currently btrfs's concept of raid0 is "stripe across as many disks
>> as possible, with a minimum of 2 disks". Is there any reason for that
>> minimum? I don't see why it can't allow only one if that's the best it
>> can manage.
>>
> That's called "Single". http://btrfs.ipv5.de/index.php?title=Mkfs.btrfs
It's called "single" if you deliberately create it that way, yes.
However, Phillip's point was, I believe, that if a striped set can start
with say five devices of varying size and drop one at a time as the
smallest devices run out of space, there's no reason it should stop at
two devices. If the goal is maximum performance, it should insist on
using only the space available in parallel across all devices and should
refuse to drop even a single one. If OTOH, the goal is maximum
utilization of available space, with a secondary goal of performance if
at all possible, then it should drop devices all the way down to a single
device, not stopping at two.
Since btrfs apparently is already content to drop from say five devices
to two despite the performance drop on the way, there's no fundamental
reason it should stop there; it should continue all the way down to a
single device, even tho when it gets to that point it's no longer
actually striped.
Of course, that's defining the behavior I'd expect of a mature btrfs.
Right now, it's still experimental, with many missing features. If at
this point there's and arbitrary line drawn at two devices minimum,
that's just the way it is. But I'd not expect that line to be there when
the filesystem is declared mature and fully ready for use.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2012-03-29 1:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-17 12:01 "not enough space" with "data raid0" Helmut Hullen
2012-03-17 12:13 ` Chris Samuel
2012-03-17 12:18 ` Helmut Hullen
2012-03-17 12:19 ` Hugo Mills
2012-03-28 18:38 ` Phillip Susi
2012-03-28 22:11 ` Alex
2012-03-29 1:07 ` Duncan [this message]
2012-03-17 12:19 ` Alex
2012-03-17 12:25 ` Hugo Mills
2012-03-17 13:36 ` Alex
2012-03-17 14:00 ` Hugo Mills
2012-03-17 14:24 ` Helmut Hullen
2012-03-17 14:43 ` Hugo Mills
2012-03-17 15:17 ` Alex
2012-03-19 15:14 ` Alex
2012-03-19 17:58 ` Hugo Mills
2012-03-19 21:45 ` Alex Plumbley-Jones
2012-03-17 13:46 ` Helmut Hullen
2012-03-17 14:04 ` Hugo Mills
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=pan.2012.03.29.01.07.05@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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.