Re: raid0 vs. mkfs

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

On Mon, Nov 28 2016, Avi Kivity wrote:
>> If it is easy for the upper layer to break a very large request into a
>> few very large requests, then I wouldn't necessarily object.
>
> I can't see why it would be hard.  It's simple arithmetic.

That is easy to say before writing the code :-)
It probably is easy for RAID0.  Less so for RAID10.  Even less for
RAID6.


>
>> But unless it is very hard for the lower layer to merge requests, it
>> should be doing that too.
>
> Merging has tradeoffs.  When you merge requests R1, R2, ... Rn you make 
> the latency request R1 sum of the latencies of R1..Rn.  You may gain 
> some efficiency in the process, but that's not going to make up for a 
> factor of n.  The queuing layer has no way to tell whether the caller is 
> interested in the latency of individual requests.  By sending large 
> requests, the caller indicates it's not interested in the latency of 
> individual subranges.  The queuing layer is still free to internally 
> split the request to smaller ranges, to satisfy hardware constraints, or 
> to reduce worst-case latencies for competing request streams.

I would have thought that using plug/unplug to group requests is a
fairly strong statement that they can be handled as a unit if that is
convenient.


>
> So I disagree that all the work should be pushed to the merging layer.  
> It has less information to work with, so the fewer decisions it has to 
> make, the better.

I think that the merging layer should be as efficient as it reasonably
can be, and particularly should take into account plugging.  This
benefits all callers.

If it can be demonstrated that changes to some of the upper layers bring
further improvements with acceptable costs, then certainly it is good to
have those too.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]