From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 23 Apr 2009 01:36:50 -0400
From: Nathaniel W Filardo <nwf@cs.jhu.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20090423053650.GR14047@masters6.cs.jhu.edu>
References: <7c22175ab60f8a5ae2cf894d462b29e5@9netics.com>
	<191db84e421c825f67aa18631ffc0884@coraid.com>
	<140e7ec30904222207r36c41d7dgbae9c320e79cfc29@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="BZziOT8Kz25R/m/E"
Content-Disposition: inline
In-Reply-To: <140e7ec30904222207r36c41d7dgbae9c320e79cfc29@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [9fans] Plan9 - the next 20 years
Topicbox-Message-UUID: ef964caa-ead4-11e9-9d60-3106f5b1d025


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

On Thu, Apr 23, 2009 at 01:07:58PM +0800, sqweek wrote:
> Ken Thompson wrote:
> | Now for the question. 9P could probably be speeded up, for large
> | reads and writes, by issuing many smaller reads in parallel rather
> | than serially. Another try would be to allow the client of the
> | filesystem to issue asynchronous requests and at some point
> | synchronize. Because 9P is really implementing a filesystem, it
> | will be very hard to get any more parallelism with multiple outstanding
> | requests.
>=20
>  I followed it up with a more focused question (awkwardly worded to
> fit within the draconian 250 character limit), but no response yet:
> "Hi Ken, thanks for your 9p/HTTP response. I guess my real question
> is: can we achieve such parallelism transparently, given that most
> code calls read() with 4k/8k blocks. The syscall implies
> synchronisation... do we need new primitives? h8 chr limit"

Not to beat a (potentially) dead horse (even further) to death, but if we
had some way of knowing that files were actually data (i.e. not ctl files;
cf. QTDECENT) we could do more prefetching in a proxy -- e.g. cfs could be
modified to do read entire files into its cache (presumably it would have to
Tstat afterwards to ensure that it's got a stable snapshot of the file).
Adding cache journal callbacks would further allow us to avoid the RTT of
Tstat on open and would bring us a bit closer to a fully coherent store.
Achieving actual coherency could be an interesting future direction (IMHO).

--nwf;

--BZziOT8Kz25R/m/E
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknv/nIACgkQTeQabvr9Tc/TFACdEgM9g46BsyeZukHUj9wfONzE
OrcAoIeKX3gRiae1o6y5Yqla35Q/maxQ
=arWo
-----END PGP SIGNATURE-----

--BZziOT8Kz25R/m/E--