linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Justin Perreault <justinperreault@dl-jp.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Wil Reichert <wil.reichert@gmail.com>,
	linux raid <linux-raid@vger.kernel.org>
Subject: Re: filesystem stripe parameters
Date: Fri, 19 Jun 2009 21:59:02 +0100	[thread overview]
Message-ID: <1245445142.18616.33.camel@Gecko.local> (raw)
In-Reply-To: <4A3B573D.5020206@msgid.tls.msk.ru>

Still learning, please be gentle.

On Fri, 2009-06-19 at 13:15 +0400, Michael Tokarev wrote:
> Wil Reichert wrote:
> > When using LVM on top of RAID 5, is it still worthwhile to pass RAID
> > stripe information to the filesystem on creation?  Or do the PE's in
> > LVM blur the specific stripe sizes & I'd want to use some multiple of
> > those instead?
> Yes it is still a good idea to pass that info because it is still a
> RAID5 which requires proper treatment wrt unaligned writes and keeping
> redundancy.
> 
> But the thing is that RAID5 and LVM are not good to each other UNLESS
> RAID5 consists of 3, 5 or 9 (or 17 etc) drives -- i.e. 2^N+1, so that
> there's 2^N data drives.
> 
> This is because LVM can only have blocksize as a power of two and in
> order to be useful that blocksize should be a multiple of RAID5 data
> row size (stripe size etc).
> 
> This is only possible when RAID5 has 2^N data drives or 2^N+1 total
> drives.  The same is for RAID4, and for RAID6 it's 2^N+2 since RAID6
> has 2 parity drives.
> 
> But if you can't match LVM blocksize and RAID strip size, there's
> *almost* no point at telling raid parameters to the filesystem: no
> matter how hard you'll try, LVM will make the whole thing non-optimal.

2.5 questions:

1) Will this same issue affect a 5+0 raid array?

2) It is inferred that one can choose to not tell the filesystem the
raid parameters, what negative effect does not doing it have?
Conversely, what is the positive effect does doing it have?

Thanks,
Justin




  parent reply	other threads:[~2009-06-19 20:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18 19:08 filesystem stripe parameters Wil Reichert
2009-06-19  9:15 ` Michael Tokarev
2009-06-19  9:36   ` Robin Hill
2009-06-19 20:59   ` Justin Perreault [this message]
2009-06-20  6:35     ` Michael Tokarev
2009-06-20  0:26   ` Wil Reichert
2009-06-20  6:19     ` Michael Tokarev

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=1245445142.18616.33.camel@Gecko.local \
    --to=justinperreault@dl-jp.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=wil.reichert@gmail.com \
    /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).