--l76fUT7nc3MelDdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 19, 2006 at 01:33:33PM +0200, Reinoud Zandijk wrote:
> Hi
>=20
> On Thu, Oct 19, 2006 at 03:40:20PM +1000, Andrew Reilly wrote:
> > On Thu, 19 Oct 2006 00:01:53 +0200
> > Reinoud Zandijk <reinoud@netbsd.org> wrote:
> > I've never looked at the code, but I would have thought that
> > there would be some sort of block-sorting/elevator-algorithm step
> > in between "this list of blocks need to go to disk" and "disk
> > drive: seek to xyz; write blocks nnn to nnn+m".  Isn't there?
> >=20
> > If there is, then this reversal probably doesn't matter much, if
> > all it does is pessimize an in-memory sort.
>=20
> Well there is some sort of disc queue sorting going on at the disc=20
> interface driver level but thats a peep-hole optimalisation that only wor=
ks=20
> for some sanity when accessed by multiple processes and asynchronous writ=
es=20
> from one processes.

peep-hole optimization? I thought we had an elevator sort in there.

> For synchronous writes this peep-hole optimalisation is not relevant sinc=
e=20
> it will wait for each write to complete before it issues a new one.

This hits on the real problem. We need to be able to issue all of the=20
writes as async and wait for all of them to complete. As SANs become more=
=20
and more accessible, we need to be able to have lots of i/o outstanding.

I'm not sure how to fix this for now, so go ahead with the list change.=20
I'm not sure if we have a good methodology for waiting on a set of=20
operations.

Take care,

Bill

--l76fUT7nc3MelDdI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFN8G5Wz+3JHUci9cRAnNAAJ0XhbtggKtmqyBKEStAn5Zmhm0CMwCfdXsg
e/mCXBB7WyP43KnQ6GuDxxk=
=GSQ+
-----END PGP SIGNATURE-----

--l76fUT7nc3MelDdI--