Re: FUSE merging?

[ebiederm@xmission.com (Eric W. Biederman)]

Eric Van Hensbergen <ericvh@gmail.com> writes:

> On Sat, 2 Jul 2005 6:15 am, Eric W. Biederman wrote:
>>
>> Taking a quick glance at v9fs and fuse I fail to see how either
>> plays nicely with the page cache.
>>
>
> True, in fact it actively avoids using it.  The previous version used both the
> page cache and the dcache with undesirable effects on synthetic file systems so
> we removed cache support.  Our intention is to design a cache layer (similar to
> cfs on Plan 9) which handles cache semantics which can be parameterized with the
> appropriate cache policy depending on the underlying file server.

Not having auto discovery for that kind of thing disturbs me.  But
if you can discover what you must do and then the policy is about
what you can do it I guess I'm fine with that.

>> v9fs according to my reading of the protocol specification does
>> not have any concept of a lease.  So you can't tell if you are
>> talking about a virtual filesystem where all calls should be passed
>> straight to the server or a real filesystem where you can perform
>> caching.
>
> While 9P contains no explicit support for leases and cacheing there is an
> informal mechanism which is used (at least for plan 9 file servers).  If the
> qid.vers is 0 the file can be assumed to be a synthetic file and so it is not
> cached.

That sounds sane.  With that you can at least do NFS style caching 
with a lot of stat calls to verify your cache is coherent and by
implementing it as a write-through cache you can even do a halfway
decent job of being cache coherent.  Which is probably about the
best you can do with the current unix API.

With a write-through cache you can likely achieve the same
semantic effect of totally not caching a file with an appropriate
number of stat calls.  Not caching some files will like yield 

I suggest you document the quid.vers == 0 magic for an uncachable
file, so future interoperability is assured.

Eric