All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.