From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 24 Jan 2006 19:25:44 -0500 From: Latchesar Ionkov To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] fuse bashing Message-ID: <20060125002544.GA8690@ionkov.net> References: <20060124201041.5A72A78FBB@dexter-peak.quanstro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060124201041.5A72A78FBB@dexter-peak.quanstro.net> User-Agent: Mutt/1.4.2.1i Topicbox-Message-UUID: e6cec434-ead0-11e9-9d60-3106f5b1d025 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. 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. 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