Re: FUSE merging?

[Andrew Morton <akpm@osdl.org>]

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...