From: Jim Salter <jim@jrs-s.net>
To: Hugo Mills <hugo@carfax.org.uk>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs-RAID(3 or 5/6/etc) like btrfs-RAID1?
Date: Thu, 13 Feb 2014 11:32:03 -0500 [thread overview]
Message-ID: <52FCF383.9090304@jrs-s.net> (raw)
In-Reply-To: <20140213162140.GW6490@carfax.org.uk>
That is FANTASTIC news. Thank you for wielding the LART gently. =)
I do a fair amount of public speaking and writing about next-gen
filesystems (example:
http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/)
and I will be VERY sure to talk about the upcoming divorce of stripe
size from array size in future presentations. This makes me positively
giddy.
FWIW, after writing the above article I got contacted by a proprietary
storage vendor who wanted to tell me all about his midmarket/enterprise
product, and he was pretty audibly flummoxed when I explained how
btrfs-RAID1 distributes data and redundancy - his product does something
similar (to be fair, his product also does a lot of other things btrfs
doesn't inherently do, like clustered storage and synchronous dedup),
and he had no idea that anything freely available did anything vaguely
like it.
I have a feeling the storage world - even the relatively well-informed
part of it that's aware of ZFS - has little to no inclination how
gigantic of a splash btrfs is going to make when it truly hits the
mainstream.
>> This could be a pretty powerful setup IMO - if you implemented
>> something like this, you'd be able to arbitrarily define your
>> storage efficiency (percentage of parity blocks / data blocks) and
>> your fault-tolerance level (how many drives you can afford to lose
>> before failure) WITHOUT tying it directly to your underlying disks,
>> or necessarily needing to rebalance as you add more disks to the
>> array. This would be a heck of a lot more flexible than ZFS'
>> approach of adding more immutable vdevs.
>>
>> Please feel free to tell me why I'm dumb for either 1. not realizing
>> the obvious flaw in this idea or 2. not realizing it's already being
>> worked on in exactly this fashion. =)
> The latter. :)
next prev parent reply other threads:[~2014-02-13 16:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 16:13 btrfs-RAID(3 or 5/6/etc) like btrfs-RAID1? Jim Salter
2014-02-13 16:21 ` Hugo Mills
2014-02-13 16:32 ` Jim Salter [this message]
2014-02-13 18:23 ` Hugo Mills
2014-02-13 20:22 ` Goffredo Baroncelli
2014-02-13 20:52 ` Hugo Mills
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=52FCF383.9090304@jrs-s.net \
--to=jim@jrs-s.net \
--cc=hugo@carfax.org.uk \
--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.