From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 24 Jan 2006 15:37:54 -0600 From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] fuse bashing In-Reply-To: <20060124201041.5A72A78FBB@dexter-peak.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060124201041.5A72A78FBB@dexter-peak.quanstro.net> Topicbox-Message-UUID: e6bd2990-ead0-11e9-9d60-3106f5b1d025 On 1/24/06, quanstro@quanstro.net wrote: > 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 > There's likely quite a bit more complexity in the 9P kernel modules.=20 As was pointed out earlier, FUSE basically just gateways VFS calls to user-space. This is an oversimplificaiton, but its not doing any of the mapping we are doing in v9fs. I'm not willing to say FUSE sucks, it is what it is, and for some folks its going to be the right solution. However, for the file systems I wanted to write, it wasn't a good match and for file systems of any complexity the FUSE user-space code seems to get out of hand quickly. Which brings up a good point for folks who are wc -l 'ing -- anyone look at the relative sizes of ramfs coded in 9P and FUSE (including their library code)? -eric