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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to