linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Soltys <soltys@ziu.info>
To: Linux Raid Study <linuxraid.study@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: LVM and Raid5
Date: Thu, 17 Sep 2009 14:37:55 +0200	[thread overview]
Message-ID: <4AB22DA3.2090901@ziu.info> (raw)
In-Reply-To: <f5d1f90a0909160122j32569fb8g9e2a212532ea8604@mail.gmail.com>

Linux Raid Study wrote:
> Hello:
> 
> Has someone experimented with LVM and Raid5 together (on say, 2.6.27)?
> Is there any performance drop if LVM/Raid5 are combined vs Raid5 alone?
> 
> Thanks for your inputs!

Few things to consider when setting up LVM on MD raid:

- readahead set on lvm device

It defaults to 256 on any LVM device, while MD will set it 
accordingly to the amount of disks present in the raid. 
If you do tests on a filesystem, you may see significant 
differences due to that. YMMV depending on the type of used 
benchmark(s).

- filesystem awareness of underlying raid

For example, xfs created on top of raid, will generally get 
the parameters right (stripe unit, stripe width), but if 
it's xfs on lvm on raid, then it won't - you will have 
to provide them manually.

- alignment between LVM chunks and MD chunks

Make sure that extent area used for actual logical volumes 
start at the boundary of stripe unit - you can adjust the 
LVM's metadata size during pvcreate (by default it's 192KiB, so 
with non-default stripe unit it may cause issues, although 
I vaguely recall posts that current LVM is MD aware during 
initialization). Of course LVM must itself start at the boundary 
for that to make any sense (and it doesn't have to be the case - 
for example if you use partitionable MD).

The best case is when LVM chunk is a multiple of stripe width, as 
in such case non-linear logical volumes will be always split 
at the stripe width boundary. But that requires 2^n data disks, 
which is not always the case.

  parent reply	other threads:[~2009-09-17 12:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-16  8:22 LVM and Raid5 Linux Raid Study
2009-09-16  9:42 ` Jon Hardcastle
2009-09-16 10:09 ` Goswin von Brederlow
2009-09-16 10:20   ` Majed B.
2009-09-16 10:33     ` Jon Hardcastle
2009-09-16 11:00       ` Majed B.
2009-09-16 13:15         ` Chris Webb
2009-09-21 17:34     ` Goswin von Brederlow
2009-09-17 12:37 ` Michal Soltys [this message]
2009-09-21 14:33   ` Mike Snitzer
2009-09-21 16:30     ` Jon Hardcastle
2009-09-21 17:26       ` Mike Snitzer
2009-09-21 17:38     ` Linux Raid Study
2009-09-21 19:14       ` Majed B.

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=4AB22DA3.2090901@ziu.info \
    --to=soltys@ziu.info \
    --cc=linux-raid@vger.kernel.org \
    --cc=linuxraid.study@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).