linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: File server structure suggestion
Date: Thu, 10 Jul 2014 21:20:44 +0000 (UTC)	[thread overview]
Message-ID: <pan$3fa75$98459e65$9560b016$e99b83a7@cox.net> (raw)
In-Reply-To: CAGTBuzTWV2jVqy4uScevHbMi-kp4_TRdeR21ZoA3-yOtCXPA=g@mail.gmail.com

Andrew Flerchinger posted on Thu, 10 Jul 2014 10:41:02 -0400 as excerpted:

> Enter btrfs. Unfortunately, it's newer than ZFS and isn't as robust, but
> it does support online capacity expansion, and the on disk format is
> expect to be stable. It has data checksums and COW, which are the
> primary things I'm after. RAID10 seems pretty stable, but RAID56 isn't.
> 
> So I'm looking for a suggestion. My end goal is RAID6 and expand it a
> drive at a time as needed. For right now, I can either:
> 
> 1) Run RAID6, but be aware of its limitations. I can manually remove and
> add drives in separate steps if needed. Keep the server on a UPS to
> limit unexpected shutdowns and any corruption there. The whole array
> can't be scrubbed, but if there is a chechsum problem when reading
> individual data, will that still be corrected and/or logged? This will
> be a temporary situation, as over time, more features will be built out,
> and the existing file system will be better supported.
> 
> 2) Run RAID10, and convert the file system to RAID6 later once it is
> stable. Since RAID10 is far more stable and feature complete than RAID56
> right now, all features will work okay, I'm just buying more
> drives/running at lower capacity for the moment. If I have to grow the
> array, I'd have to buy two drives. In the future, once RAID6 is better
> supported, I can convert in-place to RAID6.

I'd personally consider btrfs raid5/6 to be in practice a slow and lower 
capacity raid0, at this point, except that you'll get raid5/6 for "free" 
when that's fully supported, since it has been doing the writing for that 
all along, it just couldn't properly restore.  IOW, I wouldn't consider 
it trustworthy at all against loss of a device, which based on your 
suggestion, isn't appropriate for your usage.

That leaves either raid10 or raid1.  It's worth noting that btrfs raid1 
is at this point paired mirrors only, so no matter how many devices, you 
still have exactly two mirrors of all (meta)data.  N-way-mirroring is 
planned for after raid5/6 completion.  Which could put raid1 in the 
running for you, and as the simplest redundant raid, it might be easier 
to convert to raid5/6 later.

Then there's raid10, which takes more drives and is faster, but is still 
limited to two mirrors.  But while I haven't actually used raid10 myself, 
I do /not/ believe it's limited to pair-at-a-time additions.  I believe 
it'll take, for instance five devices, just fine, staggering chunk 
allocation as necessary to fill all at about the same rate.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  parent reply	other threads:[~2014-07-10 21:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10 14:41 File server structure suggestion Andrew Flerchinger
2014-07-10 14:52 ` Tamas Papp
2014-07-10 15:25   ` Andrew Flerchinger
2014-07-10 21:20 ` Duncan [this message]
2014-07-16 16:49   ` Kyle Gates

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='pan$3fa75$98459e65$9560b016$e99b83a7@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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 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).