public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Help with space
Date: Sat, 03 May 2014 12:31:30 -0400	[thread overview]
Message-ID: <536519E2.6070807@gmail.com> (raw)
In-Reply-To: <286235B8-24FE-4935-AC13-DB98F1358E32@colorremedies.com>

On 05/02/2014 03:21 PM, Chris Murphy wrote:
> 
> On May 2, 2014, at 2:23 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> 
>> Something tells me btrfs replace (not device replace, simply
>> replace) should be moved to btrfs device replace…
> 
> The syntax for "btrfs device" is different though; replace is like
> balance: btrfs balance start and btrfs replace start. And you can
> also get a status on it. We don't (yet) have options to stop,
> start, resume, which could maybe come in handy for long rebuilds
> and a reboot is required (?) although maybe that just gets handled
> automatically: set it to pause, then unmount, then reboot, then
> mount and resume.
> 
>> Well, I'd say two copies if it's only two devices in the raid1...
>> would be true raid1.  But if it's say four devices in the raid1,
>> as is certainly possible with btrfs raid1, that if it's not
>> mirrored 4-way across all devices, it's not true raid1, but
>> rather some sort of hybrid raid,  raid10 (or raid01) if the
>> devices are so arranged, raid1+linear if arranged that way, or
>> some form that doesn't nicely fall into a well defined raid level
>> categorization.
> 
> Well, md raid1 is always n-way. So if you use -n 3 and specify
> three devices, you'll get 3-way mirroring (3 mirrors). But I don't
> know any hardware raid that works this way. They all seem to be
> raid 1 is strictly two devices. At 4 devices it's raid10, and only
> in pairs.
> 
> Btrfs raid1 with 3+ devices is unique as far as I can tell. It is
> something like raid1 (2 copies) + linear/concat. But that
> allocation is round robin. I don't read code but based on how a 3
> disk raid1 volume grows VDI files as it's filled it looks like 1GB
> chunks are copied like this
Actually, MD RAID10 can be configured to work almost the same with an
odd number of disks, except it uses (much) smaller chunks, and it does
more intelligent striping of reads.
> 
> Disk1	Disk2	Disk3 134		124		235 679		578		689
> 
> So 1 through 9 each represent a 1GB chunk. Disk 1 and 2 each have a
> chunk 1; disk 2 and 3 each have a chunk 2, and so on. Total of 9GB
> of data taking up 18GB of space, 6GB on each drive. You can't do
> this with any other raid1 as far as I know. You do definitely run
> out of space on one disk first though because of uneven metadata to
> data chunk allocation.
> 
> Anyway I think we're off the rails with raid1 nomenclature as soon
> as we have 3 devices. It's probably better to call it replication,
> with an assumed default of 2 replicates unless otherwise
> specified.
> 
> There's definitely a benefit to a 3 device volume with 2
> replicates, efficiency wise. As soon as we go to four disks 2
> replicates it makes more sense to do raid10, although I haven't
> tested odd device raid10 setups so I'm not sure what happens.
> 
> 
> Chris Murphy
> 
> -- To unsubscribe from this list: send the line "unsubscribe
> linux-btrfs" in the body of a message to majordomo@vger.kernel.org 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  parent reply	other threads:[~2014-05-03 16:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 18:19 Help with space Justin Brown
2014-02-27 19:27 ` Chris Murphy
2014-02-27 19:51   ` Chris Murphy
2014-02-27 20:49     ` otakujunction
2014-02-27 21:11       ` Chris Murphy
2014-02-28  0:12         ` Dave Chinner
2014-02-28  0:27           ` Chris Murphy
2014-02-28  4:21             ` Dave Chinner
2014-02-28  5:49               ` Chris Murphy
2014-02-28  4:34 ` Roman Mamedov
2014-02-28  7:27   ` Duncan
2014-02-28  7:37     ` Roman Mamedov
2014-02-28  7:46     ` Justin Brown
2014-05-01  1:52   ` Russell Coker
2014-05-01  5:33     ` Duncan
2014-05-02  1:48       ` Russell Coker
2014-05-02  8:23         ` Duncan
2014-05-02  9:28           ` Brendan Hide
2014-05-02 19:21           ` Chris Murphy
2014-05-02 21:08             ` Hugo Mills
2014-05-02 22:33               ` Chris Murphy
2014-05-03 16:31             ` Austin S Hemmelgarn [this message]
2014-05-03 19:09               ` Chris Murphy
2014-05-03 20:52                 ` Austin S Hemmelgarn
2014-05-03 23:16                 ` Chris Murphy
2014-02-28  6:13 ` Chris Murphy
2014-02-28  6:26   ` Chris Murphy
2014-02-28  7:39     ` Justin Brown

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=536519E2.6070807@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox