All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Bob McElrath <bob@mcelrath.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: heterogeneous raid1
Date: Fri, 23 Mar 2012 10:20:07 +0000	[thread overview]
Message-ID: <20120323102007.GA14080@carfax.org.uk> (raw)
In-Reply-To: <20120323061159.GA11099@mcelrath.org>

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

On Fri, Mar 23, 2012 at 06:11:59AM +0000, Bob McElrath wrote:
> Greetings butter-heads,
> 
> I would like to implement a redundant (raid1) disk array on heterogeneous disks
> using btrfs.  A more detailed description of what I want to do can be found here:
> 
> http://superuser.com/questions/387851/a-zfs-or-lvm-or-md-redundant-heterogeneous-storage-proposal/388536
> 
> In a nutshell: organize your heterogenous disks into two "halves", the sum of
> which are of roughly equal size, and create a raid1 array across those two
> halves.
> 
> For various reasons I decided to go with btrfs over zfs.  What I have done is to
> create two lvm Logical Volumes, one using a single large disk, and another as a
> linear concatenation of several smaller disks.  It works, so far, and I could
> automate it with some scripts.

   btrfs doesn't quite do things this way. As well as the FAQ
suggested by Carey, you might want to look at the (rather misnamed)
SysadminGuide on the wiki at http://btrfs.ipv5.de/ .

> In the long term, I would like this to be something that btrfs could do by
> itself, without LVM.  Having absolutely no knowledge of the btrfs code, this
> seems easy, I'm sure you'll tell me otherwise.  ;)  But one needs:
> 
> 1) The ability to "group" a heterogeneous set of disks into the "halves" of a
> raid1.  I don't understand what btrfs is doing if you give it more than 2
> devices and ask for raid1.
> 
> 2) Intellegently rebalance when a new device is added or removed (e.g. rearrange
> the halves, and rebalance as necessary)

   A balance operation is incredibly expensive. It would be much
better to have a complex policy on when to rebalance. Think of trying
to add two new disks to a nearly-full 20TB array: you really don't
want to have to wait for 20TB of data to be rewritten before you add
the second drive. Such a complex policy doesn't belong in the kernel
(and probably doesn't belong in code, unless you've got some
mind-reading software, or a webcam and enough image-processing to
identify the stack of disks on the admin's desk).

   I'm not trying to argue that you shouldn't automatically rebalance
after a new device is added, but more that the feature probably
shouldn't be in the kernel.

   Hugo.

[snip]

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- UNIX: British manufacturer of modular shelving units. ---      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  parent reply	other threads:[~2012-03-23 10:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23  6:11 heterogeneous raid1 Bob McElrath
2012-03-23  6:47 ` cwillu
2012-03-23 10:20 ` Hugo Mills [this message]
2012-03-24  7:15   ` Duncan
2012-03-23 10:44 ` Roman Mamedov
2012-03-23 16:49   ` Bob McElrath
2012-03-23 17:13     ` Roman Mamedov
2012-03-23 17:35       ` Bob McElrath
2012-03-25 11:48         ` Chris Samuel

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=20120323102007.GA14080@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=bob@mcelrath.org \
    --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.