Re: FUSE merging?

[Miklos Szeredi]

> >
> > > >
> > > >  > - 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 :)

Then there's the usual "filesystem recursing into itself" deadlock.
Mounting with 'intr' probably solves this for NFS, but that has
unwanted side effects.  FUSE only allows KILL to interrupt a request.

> >   - efficient protocol, optimized for less context switches
> 
> One wouldn't really expect a userspace filesystem to be particularly fast,

FUSE is pretty fast.  >100Mbytes/s transfer speeds on a moderate
hardware are not unusual.

> and the performance will be dominated by memory copies and IO wait anyway.

Memory copies don't seem to be an issue (and FUSE does very little of
it).  Performance is mostly dominated by context switch times (if the
underlying filesystem can keep up).  Unfortunately unbuffered writes
mean a separate request for each written page, and thus a context
switch (on UP at least).  This has a marked effect on write
performance.

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

> >   - probably more, but I can't remember
> 
> Please do..

OK, I'll do a little research.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/