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.