From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Steve Simon" Date: Sun, 24 Jun 2007 12:38:25 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] 9P optimization In-Reply-To: <20070624030145.P1471@orthanc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 8682eb80-ead2-11e9-9d60-3106f5b1d025 > I loath the idea of pushing state into 9P, but I wonder if a combination > of client side cfs with a kqueue-like 'file is modified' server event > might not solve most of the problem. Layered into aan perhaps? Not sure if I missunderstand you but I am _not_ suggesting pushing any state into p9. My thoughts where modifying cfs heuristics to reduce the probability of waiting for a coherence check (which could be quite a few RTTs). In the limit I also suggested providing a synthetic file which contains dirstat(1) info on modified files as they change - which I think is what you mean by a "kqueue-like 'file is modified' server". The problem with implementing this as a server program on the fileserver machine is that _all_ fossil/kfs/kenfs file accesses would have to pass through this server to be sure that a when a file is changed by somone else you are informed. As fossil (what I use) already knows this info I thougt it would be as well for it to provide this file itself. hope this clarifies. -Steve