From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 10 Aug 2007 08:45:03 -0500 From: "Eric Van Hensbergen" To: weigelt@metux.de, "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 9P vs. FUSE In-Reply-To: <20070810123336.GG18939@nibiru.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070810114225.GF18939@nibiru.local> <2d66a95ea087868174cfdc519a48a2d7@9netics.com> <20070810123336.GG18939@nibiru.local> Cc: Topicbox-Message-UUID: a41f1128-ead2-11e9-9d60-3106f5b1d025 On 8/10/07, Enrico Weigelt wrote: > * Skip Tavakkolian <9nut@9netics.com> wrote: > > > did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? > > > > fuse is a clever hack for doing user space fs in unix. > > look at russ' 9pfuse in p9p. > > Okay, that's an FUSE-based 9p client. > What about FUSE-based 9p servers ? > I don't think FUSE-based 9p servers makes any sense. Over simplifying, FUSE provides a user space API into the UNIX VFS layer -- 9p provides an API and Protocol into Plan 9's file server interface (which may be local kernel, local user, or across the network). Plan 9's file server interface is an elegant (and small) approach, UNIX VFS is a much larger, more complicated (and many would argue more complicated and larger than necessary) interface. Plan 9's interface is well suited to Plan 9. UNIX's interface is well suited to UNIX. Now, that being said, we have 9p under UNIX (both in p9p and v9fs, and many other incantations), and it seems to work just fine for many things. We took a stab at extending 9p to match some of the UNIX semantics (links, special files, etc.) and it was called 9p2000.u and is implemented in the v9fs client and the spfs server code (there is an RFC if you google for it). However, it was decided at the last IWP9 that we had probably taken the wrong approach with 9p2000.u and it would probably have been better to extend 9p with new operations that had different syntax/semantics from standard 9p as these would be easier to filter out. I'm currently playing with a new design in my copious spare time. It was further suggested by some that a better approach on Linux/UNIX would have been to take what we know from 9p and design a protocol specific to the VFS (similar to FUSE but capable of transparent network, etc.) Some of the recent v9fs effort has been looking at 9p for paravirtualized file system access between hosts using shared memory transports. Much initial work has been done using 9p and 9p2000.u, but requests for more comprehensive solutions have been requested by customers/interested-parties with full support for Linux capabilities. As such, there may be a foray into providing something along the lines of a new set of extensions supporting all Linux VFS operations (perhaps I'll call it 9p2000.l) However, such support is mainly necessary for folks looking to remote access feature rich on-disk file-systems. I believe straight 9p is more than adequate for 99% of synthetic file systems with something as simple as 9p2000.u giving you extra bits necessary for basic UNIX compatibility. -eric