Messages in this thread | | | Subject | Re: FUSE merging? | From | Miklos Szeredi <> | Date | Fri, 01 Jul 2005 09:38:47 +0200 |
| |
> > > > > > > > > > > - 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |