linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: sensille <sensille@gmx.net>
To: cwillu <cwillu@cwillu.com>
Cc: Hubert Kario <hka@qbs.com.pl>,
	William Sheffler <will@sheffler.me>,
	linux-btrfs@vger.kernel.org
Subject: Re: ENOSPC on heterogeneous raid 0
Date: Sun, 12 Dec 2010 17:18:04 +0100	[thread overview]
Message-ID: <4D04F5BC.7070800@gmx.net> (raw)
In-Reply-To: <AANLkTik6q0errBWt81tMb_kpQMO6vJi5qvPJ1NS=fu-v@mail.gmail.com>

cwillu wrote:
> On Sun, Dec 12, 2010 at 8:24 AM, Hubert Kario <hka@qbs.com.pl> wrote:
>> On Wednesday 08 of December 2010 22:53:25 William Sheffler wrote:
>>> Hello btrfs community.
>>>
>>> First off, thanks for all your hard work... I have been following
>>> btrfs with interest for several years now and very much look forward
>>> to the day it replaces ext4. The real killer feature (of btrfs
>>> specifically) for me is the ability to add *and remove* devices from a
>>> filesystem, as this allows rolling upgrades of my server's disks. I
>>> have a 16 port 3ware 1650SE on which I have a number of small raid
>>> units and it will be fantastic to be able to remove the oldest,
>>> upgrade, and add the new storage back. I had previously been using
>>> ZFS, but since ZFS doesn't allow removal of devices, this rolling
>>> upgrade strategy doesn't work.
>>>
>>> My question is this: can btrfs handle striping (raid 0) across
>>> heterogeneous devices? I seem to be losing any capacity on the larger
>>> disk beyond what is available on the smaller disk. I really hope there
>>> is some simple fix!
>> Yes, it can handle stripping over devices of different size, unfortunately
>> you're still limited to <size of smallest device>*<number of devices>
>>
>> if you want to use all the available space use "-d single" when creating
>> volume
>>
>> for details, read the recent thread "800GB free, but no space left"
> 
> If I'm not mistaken, -d single doesn't mean anything yet on a
> multi-device system:  you'll still get raid0.

I don't think so. -d single does what it is expected to do. Also my recent
patch makes allocation on multi-device setups much better, although it is
not the last word on it.



      reply	other threads:[~2010-12-12 16:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-08 21:53 ENOSPC on heterogeneous raid 0 William Sheffler
2010-12-12 14:24 ` Hubert Kario
2010-12-12 15:01   ` cwillu
2010-12-12 16:18     ` sensille [this message]

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=4D04F5BC.7070800@gmx.net \
    --to=sensille@gmx.net \
    --cc=cwillu@cwillu.com \
    --cc=hka@qbs.com.pl \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=will@sheffler.me \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).