On Fri, 2002-04-19 at 03:58, Alan Cox wrote:
> > But this gets you lowest common denominator sizes for the whole
> > volume, which is basically the buffer head approach, chop all I/O up
> > into a chunk size we know will always work. Any sort of nasty boundary
> > condition at one spot in a volume means the whole thing is crippled
> > down to that level. It then becomes a black magic art to configure a
> > volume which is not restricted to a small request size.
>
> Its still cheaper to merge bio chains than split them. The VM issues with
> splitting them are not nice at all since you may need to split a bio to
> write out a page and it may be the last page
> -
I am well aware of the problems of allocating more memory in some of
these places - been the bane of my life for the last couple of years
with XFS ;-)
It just feels so bad to have the ability to build a large request and
use one bio structure and know that 99.9% of the time the lower layers
can handle it in one chunk, but instead have to chop it into the lowest
common denominator pieces for the sake of the other 0.1%.
Just looking at how my disks ended up partitioned not many of them are
even on 4K boundaries, so any sort of concat built on them would
have a boundary case which required such a split - I think, still
working on my caffine intake this morning.
Steve
--Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:24 EST