From: Hugo Mills <hugo@carfax.org.uk>
To: Hubert Kario <hka@qbs.com.pl>
Cc: nicollet@jeru.org, tom@drdabbles.us,
Gareth Pye <gareth@cerberos.id.au>,
linux-btrfs@vger.kernel.org
Subject: Re: Balance RAID10 with odd device count
Date: Wed, 22 Feb 2012 11:09:32 +0000 [thread overview]
Message-ID: <20120222110932.GC21261@carfax.org.uk> (raw)
In-Reply-To: <1591210.klPCAKoV0g@bursa22>
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]
On Wed, Feb 22, 2012 at 11:22:08AM +0100, Hubert Kario wrote:
> On Wednesday 22 of February 2012 09:56:27 Xavier Nicollet wrote:
> > Le 21 February 2012 ? 07:54, Hugo Mills a écrit:
> > > Some time ago, I proposed the following scheme:
> > > <n>C<m>S<p>P
> > >
> > > where n is the number of copies (suffixed by C), m is the number of
> > >
> > > stripes for that data (suffixed by S), and p is the number of parity
> > > blocks (suffixed by P). Values of zero are omitted.
> > >
> > > So btrfs's RAID-1 would be 2C, RAID-0 would be 1CnS, RAID-5 would
> > >
> > > be 1CnS1P, and RAID-6 would be 1CnS2P. DUP would need a special
> > > indicator to show that it wasn't redundant in the face of a whole-disk
> > > failure: 2CN
> >
> > Seems clear. However, is the S really relevant ?
> > It would be simpler without it, wouldn't it ?
>
> It depends how striping will be implemented. Generally it provides
> information on how much spindles is the data using. With static
> configuration it will be useless, but when you start changing number of
> drives in set then it's necessary to know if you're not under- or over-
> utilising the disks.
Indeed. If the implementation always uses the largest number of
devices possible, then we'll always have nS. If it allows you to set a
fixed number of devices for a stripe, then the n will be a fixed
number, and it becomes useful.
Hugo.
--
=== 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
--- Happiness is mandatory. Are you happy? ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2012-02-22 11:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-21 0:35 Balance RAID10 with odd device count Tom Cameron
2012-02-21 0:45 ` Wes
2012-02-21 0:51 ` Wes
2012-02-21 1:07 ` Tom Cameron
[not found] ` <CA+WRLO9BgqE+CwCUNgjwjVFyjDDp94SBX_EbdVciHUd0jpUqWQ@mail.gmail.com>
2012-02-21 1:59 ` Tom Cameron
2012-02-21 2:46 ` Gareth Pye
2012-02-21 7:54 ` Hugo Mills
2012-02-22 8:56 ` Xavier Nicollet
2012-02-22 10:22 ` Hubert Kario
2012-02-22 11:09 ` Hugo Mills [this message]
2012-02-21 1:07 ` Hugo Mills
2012-02-21 1:13 ` Tom Cameron
2012-02-21 1:21 ` Hugo Mills
2012-02-22 11:48 ` Duncan
2012-02-21 1:27 ` Wes
2012-02-21 1:31 ` Hugo Mills
2012-02-21 1:16 ` Liu Bo
2012-02-21 1:22 ` Hugo Mills
2012-02-21 1:13 ` 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=20120222110932.GC21261@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=gareth@cerberos.id.au \
--cc=hka@qbs.com.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=nicollet@jeru.org \
--cc=tom@drdabbles.us \
/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).