From: Ric Wheeler <rwheeler@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Chris Mason <chris.mason@oracle.com>,
Stephan von Krawczynski <skraw@ithnet.com>,
Christoph Hellwig <hch@infradead.org>, jim owens <jowens@hp.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Some very basic questions
Date: Wed, 22 Oct 2008 11:25:34 -0400 [thread overview]
Message-ID: <48FF45EE.7010001@redhat.com> (raw)
In-Reply-To: <48FF4302.5030204@redhat.com>
Avi Kivity wrote:
> Ric Wheeler wrote:
>>>
>>> Well, btrfs is not about duplicating how most storage works today.
>>> Spare capacity has significant advantages over spare disks, such as
>>> being able to mix disk sizes, RAID levels, and better performance.
>>
>> Sure, there are advantages that go in favour of one or the other
>> approaches. But btrfs is also about being able to use common hardware
>> configurations without having to reinvent where we can avoid it (if
>> we have a working RAID or enough drives to do RAID5 with spares or
>> RAID6, we want to be able to delegate that off to something else if
>> we can).
>
> Well, if you have an existing RAID (or have lots of $$$ to buy a new
> one), you needn't tell Btrfs about it. Just be sure not to enable
> Btrfs data redundancy, or you'll have redundant redundancy, which is
> expensive.
>
> What Btrfs enables with its multiple device capabilities is to
> assemble a JBOD into a filesystem-level data redundancy system, which
> is cheaper, more flexible (per-file data redundancy levels), and
> faster (no need for RMW, since you're always COWing).
I think that the btrfs plan is still to push more complicated RAID
schemes off to MD (RAID6, etc) so this is an issue even with a JBOD. It
will be interesting to map out the possible ways to use built in
mirroring, etc vs the external RAID and actually measure the utilized
capacity and performance (online & during rebuilds).
>
>> The major difficulty with the spare capacity model is that your
>> recovery is not as simple and well understood as RAID rebuilds.
>
> That's Chris's problem. :-)
Unless he can pawn it off on some other lucky developer :-)
>
>> If you assume that whole drives fail under btrfs mirroring, you are
>> not really doing anything more than simple RAID, or do I
>> misunderstand your suggestion?
>
> I do assume that whole drives fail, but RAIDing and rebuilding is file
> level. So one extent on a failed disk might be part of a mirrored
> file, while another extent can be part of a 14-member RAID6 extent.
>
> A rebuild would iterate over all disk extents (making use of the
> backref tree), determine which file contains that extent, and rebuild
> that extent using spare storage on other disks.
>
>> I don't see the point about head seeking. In RAID, you also have the
>> same layout so you minimize head movement (just move more heads per
>> IO in parallel).
>
> Suppose you have 5 disks with 1 spare. Suppose you are reading from a
> full fs. On a disk-level RAID, all disks are full. So you have 5
> spindles seeking over 100% of the disk surface. With spare capacity,
> you have 6 disks which are 5/6 full (retaining the same utilization as
> old-school RAID). So you have 6 spindles, each with a seek range that
> is 5/6 of a whole disk, so more seek heads _and_ faster individual seeks.
>
I think that this is somewhat correct, but most likely offset by the
performance levels of streaming IO vs IO with any seeks (at least for
full file systems). Certainly, the spare capacity model is increasingly
better when you have really light utilized file systems...
Don't think that I am arguing against the model, just saying that it is
not always as clear cut as you might think....
ric
next prev parent reply other threads:[~2008-10-22 15:25 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-21 11:23 Some very basic questions Stephan von Krawczynski
2008-10-21 12:13 ` Andi Kleen
2008-10-21 14:22 ` Stephan von Krawczynski
2008-10-21 15:34 ` jim owens
2008-10-22 11:36 ` Stephan von Krawczynski
2008-10-22 12:15 ` Avi Kivity
2008-10-22 13:03 ` Ric Wheeler
2008-10-22 13:13 ` Chris Mason
2008-10-22 13:16 ` Avi Kivity
2008-10-21 13:20 ` jim owens
2008-10-21 17:01 ` Stephan von Krawczynski
2008-10-21 17:15 ` Christoph Hellwig
2008-10-21 17:31 ` Ric Wheeler
2008-10-22 12:27 ` Stephan von Krawczynski
2008-10-22 13:15 ` Chris Mason
2008-10-22 13:27 ` Ric Wheeler
2008-10-22 14:32 ` Avi Kivity
2008-10-22 14:36 ` Chris Mason
2008-10-22 14:40 ` Avi Kivity
2008-10-22 14:46 ` Ric Wheeler
2008-10-22 14:54 ` Avi Kivity
2008-10-22 15:02 ` Ric Wheeler
2008-10-22 15:13 ` Avi Kivity
2008-10-22 15:25 ` Ric Wheeler [this message]
2008-10-22 15:33 ` Chris Mason
2008-10-22 15:43 ` Avi Kivity
2008-10-22 15:54 ` Ric Wheeler
2008-10-22 18:28 ` Avi Kivity
2008-10-22 15:39 ` Avi Kivity
2008-10-22 13:52 ` Stephan von Krawczynski
2008-10-22 15:56 ` Michel Salim
2008-10-22 16:56 ` jim owens
2008-10-23 9:47 ` Stephan von Krawczynski
2008-10-22 11:40 ` Stephan von Krawczynski
2008-10-21 13:59 ` Chris Mason
2008-10-21 16:09 ` Andi Kleen
2008-10-22 11:43 ` Stephan von Krawczynski
2008-10-21 16:27 ` Stephan von Krawczynski
2008-10-21 16:59 ` Andi Kleen
2008-10-22 11:46 ` Stephan von Krawczynski
2008-10-21 17:49 ` Chris Mason
2008-10-22 12:19 ` Stephan von Krawczynski
2008-10-22 12:48 ` Jeff Schroeder
2008-10-22 14:02 ` Stephan von Krawczynski
2008-10-22 13:50 ` Chris Mason
2008-10-22 14:04 ` Matthias Wächter
2008-10-22 14:32 ` Ric Wheeler
2008-10-22 14:44 ` jim owens
2008-10-24 8:42 ` Chris Samuel
2008-10-24 8:39 ` Chris Samuel
2008-10-21 20:54 ` Eric Anopolsky
2008-10-21 22:18 ` Ric Wheeler
2008-10-22 2:29 ` Eric Anopolsky
2008-10-22 10:42 ` Ric Wheeler
2008-10-22 10:53 ` Tejun Heo
2008-10-22 12:57 ` Ric Wheeler
2008-10-22 12:57 ` Ric Wheeler
2008-10-22 13:15 ` Tejun Heo
2008-10-22 13:19 ` Chris Mason
2008-10-22 13:38 ` Ric Wheeler
2008-10-22 13:59 ` Chris Mason
2008-10-22 14:23 ` Ric Wheeler
2008-10-22 13:23 ` Ric Wheeler
2008-10-22 16:14 ` Tejun Heo
2008-10-22 16:34 ` Ric Wheeler
2008-10-23 3:59 ` Tejun Heo
2008-10-22 18:32 ` Avi Kivity
2008-10-22 19:13 ` jim owens
2008-10-22 19:22 ` Avi Kivity
2008-10-22 19:59 ` Ric Wheeler
2008-10-22 21:31 ` Eric Anopolsky
2008-10-22 21:56 ` Ric Wheeler
-- strict thread matches above, loose matches on Subject: below --
2008-10-21 17:37 calin
2008-10-21 20:08 ` jim owens
2008-10-22 7:15 ` Avi Kivity
2008-10-22 14:13 ` jim owens
2008-10-22 14:25 ` Avi Kivity
2008-10-22 14:35 dbz
2008-10-27 15:43 ` Stephan von Krawczynski
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=48FF45EE.7010001@redhat.com \
--to=rwheeler@redhat.com \
--cc=avi@redhat.com \
--cc=chris.mason@oracle.com \
--cc=hch@infradead.org \
--cc=jowens@hp.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=skraw@ithnet.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.