[parted-devel] [PATCH 6/6] libparted: fix optimal IO alignment

[Brian C. Lane]

On Wed, Dec 19, 2012 at 09:41:00PM +0100, Jim Meyering wrote:
> Phillip Susi wrote:
> > On 12/19/2012 11:45 AM, Jim Meyering wrote:
> >> Phillip Susi wrote:
> >>> Sure, take a 4 disk raid5 with 256k stripe factor.
> >>
> >> Am I misunderstanding something? 256k is both smaller than 1MiB and
> >> *is* a power of 2. I was asking if you'd seen values *not* like
> >> that.
> >
> > A 4 disk raid 5 with 256k stripe factor uses 256k from each of 3 disks
> > ( 4th is parity ), giving a stripe width and thus an optimal alignment
> > of 768k.
> 
> Ok, that makes sense.
> Then what do you think about lowering the bar from 1MiB to 128KiB?
> Maybe even 64KiB, I suppose.  Better safe than sorry.
> Just look at how many people are still reporting problems
> with parted 1.8, so many years later.
> 
> >> I guess it comes down to whether there are systems that return
> >> bogus values there, and whether there are systems that return legit
> >> values smaller < 1MiB, like I was asking about above.
> >
> > I'm not aware of any known bugs where the kernel returns inappropriate
> > values, but there are plenty of raid configurations that do use < 1MiB
> > and/or non power of two alignments.
> 
> I'm pretty sure those tests do actually serve some purpose.
> Maybe Brian (Cc'd) knows for sure?
> (Brian, this is about the use of PED_DEFAULT_ALIGNMENT, aka 1MiB
> in commit c749046a54d983f74f8156c0aea71b0995b9477d)

I am naturally reluctant to change things without a specific problem. If
I'm reading the bug correctly this was mostly to clean up some corner
cases, it was already using 1MiB most of the time.

I really don't know anything about what the kernel returns when. Isn't
it usually up to the admin to setup special cases like RAID?

In my experience with hardware (generally, not any specific device)
there is always someone who gets it wrong. So unless the kernel takes
this into account we should keep some sanity checking in parted.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20121219/9af058b9/attachment.pgp>