From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 12 Nov 2008 08:48:58 -0600 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <043B2467-EE87-4262-8BD6-49FFDB83CFC0@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1226365206.17713.390.camel@goose.sun.com> <29302f743a99f05c1d9ac196b0245f81@9netics.com> <5d375e920811110830k1c91a401y5e6f39f1737d4240@mail.gmail.com> <140e7ec30811110954u44f8f9aeg788dc34b7d35ac69@mail.gmail.com> <140e7ec30811111811i15f2e2bp3761d477e6c90aed@mail.gmail.com> <043B2467-EE87-4262-8BD6-49FFDB83CFC0@sun.com> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 3f16edf8-ead4-11e9-9d60-3106f5b1d025 On Tue, Nov 11, 2008 at 9:51 PM, Roman Shaposhnik wrote: > On Nov 11, 2008, at 6:11 PM, sqweek wrote: >> >> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen >> wrote: >>> >>> I have two measurements of success: >>> a) what keeps me working on Plan 9 related technologies in a paid >>> position >>> b) what switches people from using NFS, GPFS, or other horribly >>> complicated solutions to something closer to Plan 9 >> >> Fair enough. Does .L still qualify as "closer to Plan 9", or is it >> NFS by any other name? > > NFS (especially NFS4) seems to be exactly the POSIX-oriented 9P. > Except one thing: they worry too much about caching and that > show in various places in the protocol. NFS3 is also stateless. > An important consideration (and quantifiable difference): 9p-rfc.txt -- 47 pages nfsv4-rfc.txt -- 275 pages What's particularly interesting there is that the nfsv4.txt is incomplete -- in order to implement the protocol you have to go reference the RFC's on dozens of sub-protocols and side protocols. The 9p-rfc.txt is fundamentally complete, with the only exception being the requirement of a separate spec for the authentication mechanisms. Now, even though 9P.L will grow the specification somewhat (in that there will be many new op-codes), the definition of those protocol elements are trivial and I don't believe it'll boost us to 275+ pages. Another considering (and quantifiable difference): 9P Client (in Linux kernel including virtio, fd, & RDMA transports) Total Physical Source Lines of Code (SLOC) = 5,233 9P Client (npfs ufs.c) Total Physical Source Lines of Code (SLOC) = 5,454 NFS Client (in Linux kernel only including socket interface) Total Physical Source Lines of Code (SLOC) = 43,903 NFS Server Code (in Linux kernel) Total Physical Source Lines of Code (SLOC) = 15,106 NFS Userspace Support Utils (required for server op) Total Physical Source Lines of Code (SLOC) = 35,468 These aren't apples to apples kinds of comparisons. NFS has more features, 9P has more transports (in the above comparison, I didn't have the time to track down the NFS/RDMA patch and there is no NFS/virtio patch that I am aware of). Again, the introduction of 9P.L will grow our line count a bit -- however, nearly all of the added operations are just proxy operations. That is, all they do is marshall and unmarshall VFS operands and responses and map those operations to FIDs versus dentry pointers or file pointers. This is extremely straightforward and there is likely to be more lines taken up by boilerplate than implementation. As such, I don't see the overall line count or code complexity increasing dramatically on the protocol side. The largest line count increase will likely be from having alternative "fs" interfaces for 9P versus 9P.L -- but this will largely be boilerplate, not new complex code. I use 9P versus NFS (or some other remote file system) for three particular reasons: * its approachable - I can understand it and understand what's going on without slogging through layers of crap * I can trivially implement a fully functioning server in a weekend or less (this is an area we can do better on as well) * its default semantics with respect to caching are closer to what I need for the sorts of distributed systems I work with * it is fairly straightforward to support new transports, and in the Linux kernel implementation it's getting easier. This is important for me because not everything I deal with is a socket. These reasons make sense to me no matter what environment I'm in (be it Linux, Plan 9, or whatever). Its certainly possible there are other solutions and protocols, and I have no doubt things can be done better. But experience with using these things in actual large scale deployments is the most valuable indicator of what tools works best for what applications. -eric