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

Karel Zak kzak at redhat.com
Thu Dec 20 10:33:48 UTC 2012


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

 Well, it maybe hardware who reports inappropriate values. This is
 reason why we default *everywhere* to 1MiB offset and grain.

 If I good remember the initial discussions about I/O limits years ago 
 then we have few rules:

  - always use 1MiB offset for the first partition and align partition
    size (grain) to to MiBs if this 1MiB setting is compatible I/O
    limits

  - if HW does not report I/O limit then use 1MiB rule

  - if device I/O limits are smaller then 1MiB, but compatible with
    1MiB then use 1MiB rule

> > values, but there are plenty of raid configurations that do use < 1MiB
> > and/or non power of two alignments.

 then the device (e.g. /dev/mdN) reports optimal I/O limit that is
 incompatible with the 1MiB rule (for example 768k optimal I/O), right?


    Karel

-- 
 Karel Zak  <kzak at redhat.com>
 http://karelzak.blogspot.com



More information about the parted-devel mailing list