On Wed, Sep 04, 2002 at 01:57:52PM -0700, Jason R Thorpe wrote:
> On Wed, Sep 04, 2002 at 10:50:17PM +0200, Manuel Bouyer wrote:
> 
>  > But in this case wouldn't they already be adjacent at the upper level ?
>  > What we say here is that MAXPHYS for a raid-0 raid is the sum of the MAXPHYSs
>  > of the underlying devices.
> 
> Why would they already be adjacent at the upper level?  The RAID driver
> simply chunks up the larger transfer into smaller ones at the correct
> offsets and fires them off.  (For a simpler version, look at ccd.c)

Hum, yes you're right. They may not be adjacent, just at offsets multiples of
the strip size.

> 
>  > Hum, I didn't consider the case when the stripe unit size is smaller
>  > than the underlying MAXPHYS. Really raidframe's MAXPHYS is n*stripe unit size.
> 
> Right, RAIDframe (or ccd) is going to get at most a MAXPHYS-sized transfer
> in the current scheme.  Maybe it gets several of those.  It fires them off,
> and when it does so essentially guarantees that the request for each component
> device is going to be < MAXPHYS (for simple RAID-0, the best you can hope for
> is min(interleave_size, MAXPHYS/num_components), right?)

Yes. This is why going to a variable, per-disk MAXPHYS can help here:
raidframe could use a much larger MAXPHYS than the underlying disks in
some cases.
As you explained, it won't cover all cases where requests could be merged at
the underlying device. But still I think it's worth it :)

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--