Re: Patch??: linux-2.5.20/fs/bio.c - ll_rw_kio could generate bio's

[Andrew Morton]

"Adam J. Richter" wrote:
> 
>         Here is version 4 of my changes to fs/bio.c (ll_rw_kio) and
> fs/mpage.c.  Andrew, I believe it this accomodates all of your
> requests.  Please let me know if I missed anything.  If it looks
> good, I would apperciate your recommendation on how to proceed with
> getting this into Linus's tree.

mpage stuff looks good.

We need to wake Jens up before going any further.  (The test
for ->max_sectors != 0 look funny).

The main issue is that this code will now permit really
big BIOs.  Up to a megabyte.  That'll work OK on just-a-disk,
but apparently ->max_sectors isn't worth squat for stacked
devices.

Back in March I was told "That's why BIO_MAX_SIZE exists. It's the
size it is due to typical hardware restrictions :-/".  Well,
we see here that your Smart2 RAID controller has just blown that
idea out of the water.

Also this:

:> Actually: what about the case where we're not using any device
:> stacking at all?  Where we're just talking to a plain old
:> disk?  That's a common case, and it's worth optimising for.
:
:That would be doable. Just require stacking drivers to mark the queue as
:such -- so md etc would do something ala blk_queue_stacked(q) and that
:would just set the QUEUE_FLAG_STACKED flag. Then we know that
:q->max_sectors indeed can be trusted completely.

Now this idea would let us assemble large BIOs nicely against
"just a disk".  But we'd still need BIO_MAX_SIZE, and your
RAID controller will still explode when stacked upon.

What you can do short-term is (yech) teach bio_max_iovecs() to
not return a value greater than 64 kbytes.

Longer term, we really need a way of propagating the "max request size"
info up the stack.  At a minimum we need to do this statically.

Ideally we do it dynamically, passing in the starting sector, so
we can calculate the maximum-sized BIO correctly each time and
we never need to get into BIO-splitting horrors.

-