From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 31 Oct 2007 18:32:03 -0500 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] QTCTL? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8ccc8ba40710311526o4a5e55a7wf04f12844d4d4b66@mail.gmail.com> Cc: V9FS Developers Topicbox-Message-UUID: e264d17a-ead2-11e9-9d60-3106f5b1d025 On 10/31/07, Charles Forsyth wrote: > > QTCL would ... > > perhaps one of my points is that in the Plan 9/Inferno world, you'd > be better off marking the files you can cache, not trying to identify the ones > that you can't. one reason is the practical one of having to touch perhaps two or > maybe three important servers instead of everything. > That makes a lot of sense -- particularly in a Plan 9 context. It should be straightforward enough to modify appropriate "static" content file servers to set this bit. The current range of non-Plan9 servers (u9fs,spfs,etc.) present a bit of difficulty in that there isn't a good way to transitively detect this sort of thing when say a p9p server is mounted on Linux and then re-exported, mapping it through the Linux VFS space. But then I suppose that's just a matter of not using the aforementioned tools to export "special" files or file systems. I've got some ideas to fix this that I want to play with using Lucho's new in-Linux-kernel-9p-server. Of course, all of this is probably a corner case that most people don't see anyways. In the context of FastOS, dealing with thousands of nodes, we are going to need to implement more sophisticated forms of caching. Since this is going to be pretty critical to even booting at larger scale, its likely we'll be digging into this early next year. We'll keep folks in the loop as we get prototypes working. -eric