From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.17]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6PMYdu6006011 for ; Wed, 25 Jul 2012 18:34:39 -0400 Received: from Ishtar.sc.tlinx.org (ishtar.tlinx.org [173.164.175.65]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6PMYcSZ006081 for ; Wed, 25 Jul 2012 18:34:38 -0400 Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.5/8.14.4/SuSE Linux 0.8) with ESMTP id q6PMYZfQ021992 for ; Wed, 25 Jul 2012 15:34:37 -0700 Message-ID: <5010747B.10908@tlinx.org> Date: Wed, 25 Jul 2012 15:34:35 -0700 From: Linda Walsh MIME-Version: 1.0 References: <500C44EF.4080004@tlinx.org> <20120725210434.GA20135@redhat.com> In-Reply-To: <20120725210434.GA20135@redhat.com> Content-Type: multipart/alternative; boundary="------------030303080700060704080401" Subject: Re: [linux-lvm] RFE? Really power of 2? extents, chunks and raid alignment Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: LVM general discussion and development This is a multi-part message in MIME format. --------------030303080700060704080401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. --------------030303080700060704080401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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.

--------------030303080700060704080401--