From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5246019a38a046d37b3681f3c44e36e3@quanstro.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] The Web9 Project From: erik quanstrom Date: Sun, 9 Sep 2007 07:55:47 -0400 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: bc2ec664-ead2-11e9-9d60-3106f5b1d025 > We already agreed on a solution. Nobody is interested in implementing i= t. >=20 > On 9/8/07, Uriel wrote: >> > > have you compared its performance to webdav? >> > >> > I don't have any numbers with me, but I would expect 9P to work >> > faster than WebDAV since 9P works one layer below HTTP. >> > Implementation details aside, header-overhead in itself makes WebDAV >> > a less of a competitor. >> >> Maybe, if you have ridiculously low latency. Which is one of the >> reasons I would like to see the latency issues addressed, so 9P >> services can work well over non-LAN networks. Maybe we can finally >> agree on a solution for this at this year's IWP9? this topic has come up before. i'm not sure i have a clear picture of th= e problem. would someone give a concrete example? without really knowing what the problem is, there is one big thing that 9p clients traditionally don't do that would be enormously helpful for larger files -- readahead. there's nothing in 9p that prevents a client = from having R outstanding reads at the same time. if l is the rtt latency and s is the avg time it takes the fs to service a request, we can try to pic= k a (reasonable) number of outstanding requests R s.t. Rs =E2=89=A5 l. even = if we can't, N outstanding should reduce the latency penalty for N packets to l, not Nl. if instead the problem is lots of little files the proposals i've seen are something like bundles of 9p requests. sent en mass to the fs. how about the opposite? why not bring the blocks en mass to the fs? the remote fs could be treated as a block storage device (we know how to do readahead on these things) and the "fs" could be run locally. the "fs" a mkfs archive, mbox format, a fossil fs or whatever. unfortunately, if the problem is fine-grained, highly concurrent access, readahead just won't work. - erik