From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Steve Simon" Date: Sun, 24 Jun 2007 10:34:16 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] 9P optimization In-Reply-To: <13426df10706232108o4ab432a7p5afc662ec9ef711b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 8671dd22-ead2-11e9-9d60-3106f5b1d025 > http://mbgokhale.org/rminnich/job/autocacher/autocache.ps Interesting idea, I must read up on what else has been published on cache= ing to avoid high latency links. It would be fun to modify cfs to have a couple of cache coherency algorit= hms, the timeout you describe could be one, Boyds ftp cache rule is also inter= esting - the timeout value is proportional to how long ago the file was last writt= en, so old files tend to be stable. The cache could be dynamic on the device type on which the file lives, fossil/kfs/kenfs get timeouts, others are assumed to be synthetic files a= nd so should have their verson numbers checked every time as cfs does now. We could even implement a /dev/fossilchg file which contains the dirstat(= 2) info of all modified files as they change. This would allow persistant (or at = least long lived) connections to attempt to keep a near consistant view of the = file. That is any file which has had an update since the local cfs has been sta= rted would have a known state (be it consistant or inconsisitant); similarly a= ny file who had to have its version checked would have a known state also. This is of course a seperate issue to the coelessing of multiple p9 opera= tions in a single packet as, though as previous posters pointed out it would he= lp cfs too. my 2=C2=A2 -Steve