All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob McElrath <bob@mcelrath.org>
To: Roman Mamedov <rm@romanrm.ru>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: heterogeneous raid1
Date: Fri, 23 Mar 2012 17:35:39 +0000	[thread overview]
Message-ID: <20120323173539.GC11099@mcelrath.org> (raw)
In-Reply-To: <20120323231307.283be0fb@natsu>

Roman Mamedov [rm@romanrm.ru] wrote:
> On Fri, 23 Mar 2012 16:49:32 +0000
> Aye, but I consider space used for redundancy to be wasted as well, especially
> when the same (or even higher) amount of redundancy can be achieved by spending
> less storage space on it.

Point taken.  So how's the btrfs raid6 implementation coming along?  ;)

> Again no argument here, just wanted to throw the link out there as it was an
> eye opener for me, and for my primary storage I currently use a 6-member RAID6
> consisting of 5x 2TB physical disks and a 2TB RAID0 from 1.5TB+500GB (yes,
> mdadm can also do RAID0 of differently-sized drives! it'll stripe while it
> can, and after that it's just the tail of the larger drive).

I actually came up with that same algorithm, before switching to the simpler
raid1 arrangement.  The former provides more redundancy, at the expense of a
*lot* more complexity.  Having rebuilt raid arrays by hand, it's not so
difficult to make a mistake there, and nuke your array, rendering your fancy
2-disk failure protection moot.  e.g. one can also issue the wrong set of
commands to btrfs and zero the superblock by accident (or so I read)...in my
case it was a motherboard that rearranged sda/sdb/sdc on each boot, and older
mdadm which didn't handle that gracefully.  If that author had provided some
nice scripts that do what he described, I'd test it, but I didn't see any...

In my proposal I'm unhappy to have to use lvm at all, and would like to remove
that dependency, in the interest of fewer chances to fuck up during a
failure/rebuild.

I'm still dreaming of a fs/admin tool that I can throw disks at, and not have to
spend so much time with the details of partitioning/raid/lvm/fs.  Imagine a
"pool" with check-boxes for how much redundancy you want, and it tells you how
much space you'll have.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche

  reply	other threads:[~2012-03-23 17:35 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
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 [this message]
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=20120323173539.GC11099@mcelrath.org \
    --to=bob@mcelrath.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rm@romanrm.ru \
    /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.