On Thu, Sep 18, 2008 at 05:57:21PM +0800, sqweek wrote: > On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom <[EMAIL PROTECTED]> wrote: > > as an aside: i don't think 9p itself limits plan 9 performance > > over high-latency links. the limitations have more to do with > > the number of outstanding messages, which is 1 in the mnt > > driver. > > Hm, but what's the alternative here? Readahead seems somewhat > attractive, if difficult (I worry about blocking reads and timing > sensitive file systems). But there's one problem I can't resolve - how > do you know what offset to Tread without consulting the previous > Rread's count? > Actually, I understand there has been discussion about grouping tags > to allow for things like Twalk/Topen batching without waiting for > Rwalk (which sounds like a great idea), maybe that would work here > also... > -sqweek >
This seems an appropriate time -- well, appropriate thread, if a few days lagged -- to bring up Dave's/my cache journaling scheme for review... I presented this at IWP9 last year and recieved mostly positive feedback, as I remember, but sadly have not had a chance to work on it since. (That said, it remains on my todo list should nobody beat me to it.) The protocol design is documented on my server at https://wiki.ietfng.org/pub/Plan9/JournalCallbacks. Sadly, it remains the case that I don't have an implementation to offer. The basic idea is to shim a client-side cache and a server-side cache controller in front of a filesystem, like fossil or exportfs, and have the cache controller snoop on all connections to the server, informing caches when the contents of their caches have become invalid. There are a few known deficiencies ([in]coherency and authentication being the two big ones), but I hope the idea remains sound. Thoughts and criticisms welcome. :) --nwf;
pgpVHCVN6sT7c.pgp
Description: PGP signature
