Re: FUSE merging?

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

Miklos Szeredi <miklos@szeredi.hu> writes:

>> > What would people say if ext3 was always mounted locally through NFS,
>> > because the kernel would only provide the NFS filesystem client.
>> 
>> Probably the same thing they would say if ext3 was a user-space
>> application that always needed to be mounted via FUSE ;)
>
> Yes, and rightly.
>
> One of the misunderstandings about userspace filesystems (Linus falls
> into this) is to compare it with microkernels.
>
> FUSE (and userspace filesystems in general) are NOT meant to replace
> in kernel filesystems or the VFS.  They are an addition with which
> different kinds of filesystems can be implemented much better than
> they could be in kernel.

Taking a quick glance at v9fs and fuse I fail to see how either
plays nicely with the page cache.

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.  The implementation simply appears to bypass the pagecache
which seems sane.

Skimming through the FUSE code I see the same problem, in that you can't
autodetect the right thing.  This is currently hacked around with
"direct_io" mount option selecting between a cached and a non-cached
status on a filesystem basis at mount time.  But having
a per file flag would be nicer.  I also don't understand
why in fuse direct_io is an if statement in fuse_file_read/write
instead of simply being a different set of filesystem operations.

Neither implementation seems to forward user space locks to the
filesystem server.

Eric