Messages in this thread | | | Subject | Re: FUSE merging? | From | (Eric W. Biederman) | Date | Sat, 02 Jul 2005 04:01:45 -0600 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |