Re: [9fans] Do we have a catalog of 9P servers?

["Eric Van Hensbergen" <ericvh@gmail.com>]

On Tue, Nov 11, 2008 at 9:51 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 11, 2008, at 6:11 PM, sqweek wrote:
>>
>> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <ericvh@gmail.com>
>> 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