Messages in this thread | | | Date | Fri, 1 Jul 2005 01:02:29 -0700 | From | Andrew Morton <> | Subject | Re: FUSE merging? |
| |
Miklos Szeredi <miklos@szeredi.hu> wrote: > > > > > > > > > > > > > > > - aren't we going to remove the nfs semi-server feature? > > > > > > > > > > I leave the decision to you ;) It's a separate independent patch > > > > > already (fuse-nfs-export.patch). > > > > > > > > Let's leave it out - that'll stimulate some activity in the > > > > userspace-nfs-server-for-FUSE area. > > > > > > > > Speaking of which, dumb question: what does FUSE offer over simply using > > > > NFS protocol to talk to the userspace filesystem driver? > > > > > > Oh lots: > > > > > > - no deadlocks (NFS mounted from localhost is riddled with them) > > > > It is? We had some low-memory problems a while back, but they got fixed. > > During that work I did some nfs-to-localhost testing and things seemed OK. > > Well, there's the "unsolvable" writeback deadlock problem, that FUSE > works around by not buffering dirty pages (and not allowing writable > mmap). Does NFS solve that? I'm interested :)
I don't know - first you'd have to describe it.
> Then there's the usual "filesystem recursing into itself" deadlock.
Describe this completely as well, please.
> Mounting with 'intr' probably solves this for NFS, but that has > unwanted side effects. FUSE only allows KILL to interrupt a request.
Maybe these things can be solved in NFS?
> > > - dcache invalidation policy > > > > What's that? > > Userspace can tell the kernel, how long a dentry should be valid. I > don't think the NFS protocol provides this. Same holds for the inode > attributes.
Why is that needed?
> > > - probably more, but I can't remember > > > > Please do.. > > OK, I'll do a little research. >
v9fs has a user-level server too. Maybe it has been used in FUSE-like scenarios more than NFS.
Plus NFS and v9fs work across the network... - 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/
| |