All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linda Walsh <lvm@tlinx.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] RFE?  Really power of 2?  extents, chunks and raid alignment
Date: Wed, 25 Jul 2012 15:34:35 -0700	[thread overview]
Message-ID: <5010747B.10908@tlinx.org> (raw)
In-Reply-To: <20120725210434.GA20135@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]





Mike Snitzer wrote:
>
>> I have 12 data disks in a RAID 50 (3 RAID5's in a RAID0) and use a suggested
>> stripesize of 64k, so a stripe-width of 768k.
>>     
I must state this correction -- to the above -- I was thinking I had to
use the least common multiplier -- but in reality, I _think_ (subject to
later revision, both -- reality and what I think, ;-)), I should be able to
use the greatest common denominator  and that should work
equally well.

Nevertheless, this:
>
> The DM update for the 3.6 merge window adds non power of 2 support in
> the kernel (for the stripe and thin-pool targets).
>
> So the lvm2 constraints that require a power of 2 chunksize will be
> relaxed very shortly.
>   
is great news, as I'm sure that being able to synchronize stripes to
chunksize AND extent size, would allow better performance for RAID aware
file systems...

I.e. As it is now, I need to have my extents line up, my chunks line up
AND my file system block allocations line up....*ouch*....

If any of those start at 'fixed offsets' from the beginnning of their
space and that fixed size isn't a multiple of the extent size (for VG's)
OR chunksize for LV's, then all of the VG's/LV's will won't line up --
this is only an issue if you have multiple VG's per PV (i.e. the PV's
will use the same physical disks, and the LV's would also use the same
disks, but what you thought was an aligned database mirrored in
1 partition might be completely non-aligned if anything under it is
    misaligned.

I very well do NOT know, the full impact of such -- only that it would
cause unpredictable or variable performance, which as an engineer,
bothers me.




[-- Attachment #2: Type: text/html, Size: 5612 bytes --]

      reply	other threads:[~2012-07-25 22:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-22 18:22 [linux-lvm] RFE? Really power of 2? extents, chunks and raid alignment Linda Walsh
2012-07-25 20:06 ` Lars Ellenberg
2012-08-01 23:32   ` Linda A. Walsh
2012-07-25 21:04 ` Mike Snitzer
2012-07-25 22:34   ` Linda Walsh [this message]

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=5010747B.10908@tlinx.org \
    --to=lvm@tlinx.org \
    --cc=linux-lvm@redhat.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 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.