One thing that Op taught us was that it´s quite nice to add changes in the protocol just by NOT changing the protocol, and putting special servers-clients as gateways.
We could implement a export for caching clients (and a caching client) so that the export implements the Tinval-Rinval thing, and serves the caching clients. The export process may export its own namespace (perhaps just with the main fileserver mounted) and the caching clients would behave as 9p servers to others in their machines. This worked just fine in Inferno and could work if we try it in Plan 9. Also, I´m now thinking that we could take advantage of these new xport-cache links to avoid some RPCs. To maintain 9p semantics we could not use op in there, but perhaps there´s something in the middle. I have to give this all more thought. Any comment on this, though? On 11/1/07, Francisco J Ballesteros <[EMAIL PROTECTED]> wrote: > We did look at nfs v3 and lbfs before implementing op. > > nfs v3 at least tried to address latency and not just bandwidth as lbfs, > but it seemed to use more RPCs than needed for some tasks (I don´t remember > now, but have that written down somewhere). > > > > On 11/1/07, ron minnich <[EMAIL PROTECTED]> wrote: > > right, but before the experiments start in earnest, see what they're > > doing at lustre.org, in nfs v3, etc. > > > > Much of this discussion is familiar. > > > > <shameless plug> you can also see what I did in mnfs ca. 1992, if you > > promise to ignore the use I put it to (DSM). I implemented invalidates > > for shared pages. It took, like 15 minutes to implement. It required > > that I run an nfs server on each client, however, and it worked > > because NFS blocks on a node have a global name: <fhandle>:<offset>. > > So the server tracked who had what pages, and an invalidate was > > actually a simple RPC from servers to clients. yes, this broke the > > c-s-c model, but hey ... I like it better than leases, personally. > > > > But neither this nor leases seems to scale terribly well to 4096 or > > more clients. > > > > ron > > >
