Re: [9fans] fuse bashing

[erik quanstrom <quanstro@quanstro.net>]

On Tue Jan 24 18:24:33 CST 2006, lucho@gmx.net wrote:
> On Tue, Jan 24, 2006 at 02:10:41PM -0600, quanstro@quanstro.net said:
> > On Mon Jan 23 20:21:36 CST 2006, lucho@gmx.net wrote:
> > > On Mon, Jan 23, 2006 at 12:06:09PM -0500, Russ Cox said:
> > > > It appears to match the kernel better, so the implementation
> > > > should be simpler.  (As soon as you want to talk between
> > > 
> > > It is much simpler (and probably faster), and that's a big win for FUSE:
> > > 
> > > 	$ cat fs/fuse/*.[ch] | wc -l
> > > 	4073
> > > 
> > > 	$ cat 9p/*.[ch] | wc -l
> > > 	7271
> > 
> > why do you assume that line count is porportinal to
> > speed of execution or complexity?
> 
> Because it doesn't need to convert an alien protocol to Linux VFS. It
> doesn't need to care about converting error strings to error codes,
> architecture independent format for the values etc.

even so, these sound like simple translations. they may produce more
code, but i'm not sure they add complexity.

> It doesn't need to care
> about unix and tcp sockets. In fact I tested the speed of fuse+fusexmpl
> compared with v9fs+u9fs, and fuse is noticeably faster.

why didn't you say so? ;-)

i don't use u9fs; was there any indication that v9fs in the kernel was slow?
have you tried any p9p fileservers? tapefs seemed speedy enough:

; 9p ls tapefs
--rw-r--r-- M 0 1000 100 6749246 Feb  5  1998 cyberbit.zip
; time 9p read tapefs/cyberbit.zip > /dev/null
0.18user 0.20system 0:01.07elapsed 36%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+404minor)pagefaults 0swaps

; time cat 9/tapefs/cyberbit.zip > /dev/null
0.00user 0.01system 0:01.15elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+146minor)pagefaults 0swaps

> 
> If FUSE doesn't handle the interrupts well, that in part explains why is it
> smaller. The proper signal handling is one of the most complex parts in v9fs.
> 
> Thanks,
>         Lucho