If you've ever wondered how the NFS protocol is maintained, designed, discussed, etc, now is a great time to watch it happen live. James Lentini has proposed a method to allow client to initiate a file "copy" from one location to another on the same server. With the traditional method, the client has to read the file from the server and then write it back. With the COPY proposal, all of that overhead is removed.

That part is pretty pedestrian and not being debated. What is being debated is a server-to-server copy proposal. You can see the benefits here:

                                         /
                                         /
             Existing approach           /            New COPY procedures
  Client           Source   Destination  / Client           Source   Destination
    +                +          +        /   +                +          +
    |                |          |        /   |                |          |
1   |>--get FH------>|          |        /   |>-COPY_NOTIFY-->|          |
    |               /|          |        /   |               /|          |
    |              / |          |        /   |              / |          |
    |             /  |          |        /   |             /  |          |
2   |<-----------+   |          |        /   |<-----------+   |          |
    |                |          |        /   |                |          |
    |                |          |        /   |                |          |
3   |>--get FH----------------->|        /   |>--COPY------------------->|
    |                |         /|        /   |                |         /|
    |                |        / |        /   |                |        / |
4   |<-----------------------+  |        /   |<-----------------------+  |
    |                |          |        /   |                |          |
5   |>--read-------->|          |        /   |                |<--read--<|
    |               /|          |        /   |                |\         |
    |              / |          |        /   |                | \        |
    |             /  |          |        /   |                |  \       |
6   |<-----------+   |          |        /   |                |   +----->|
    |                |          |        /   |                |          |
7   |>--write------------------>|        /   |                |<--read--<|
    |                |         /|        /   |                |\         |
    |                |        / |        /   |                | \        |
    |                |       /  |        /   |                |  \       |
8   |<----------------------+   |        /   |                |   +----->|
    |                |          |        /   |                |          |
9   |>--read-------->|          |        /   |                |<--read--<|
    |               /|          |        /   |                |\         |
    |              / |          |        /   |                | \        |
    |             /  |          |        /   |                |  \       |
10  |<-----------+   |          |        /   |                |   +----->|
    |                |          |        /   |                |          |

Don't read anything into the length of a horizontal request, i.e., the read at time 5 is not twice as fast as the write at time 7. Assume that everything is just 1 network hop away.

Also, ignore that we can have multiple reads or writes in flight. In the end, you can see that we will issue almost 1/2 the number of over the wire calls if we let the servers handle the copy.

And the mailing list is full of lively discussion about how to do this - there isn't a disagreement that it is a bad thing to do. Instead the discussion is all about how to implement it.

Rather than bias you towards my view, you can go watch the action in either the thread archives or join the working group alias nfsv4 -- NFSv4 Working Group.

I decided to undertake the editing of RFC3530bis, which is a second effort on RFC3530. The intent is to make the document cleaner, but to not introduce any over-the-wire protocol changes. (We have NFSv4.1 for that.)

The main effort so far has been in taking the text version of RFC3530 and converting it to XML. The reason to do that is that it really makes it easy to organize the layout. Effectively, this is just like keeping my thesis in LaTeX. Plus I always love compiling a document. The previous version of the document had been maintained in troff and the known source was out of sync with the official document.

So now you can look at the documents here:

1. draft-ietf-nfsv4-rfc3530bis-00.txt [draft]
2. draft-ietf-nfsv4-rfc3530bis-dot-x-00.txt[draft]

The first major change was the pulling of the XDR description of NFSv4.0 out of the main document and into a separate one. That allows for the easy creation of your own .x file from that document.

I had an Ultra 24 waiting for me at the Tulsa offices, and really, I never knew we had a Tulsa office and that it was a quarter mile from my house.

The machine was dead quiet when I turned it on and then it started to roar. The fans would not go off. The machine would actually not boot at all. All I could find were these forum posts - Ultra 24 FAN speed. I downloaded the 1.5 version of the BIOS and that did not help. After the reboot, the fans were still going. I then turned the machine off as I checked to make sure I hadn't disconnected anything when I added RAM. I hadn't, but the machine started to work after that. :->. I believe what was effectively a cold reboot enabled that.

The other thing I did notice is that the system came with Solaris 10. I went through the initial install screens and they appeared to be as sluggish as I remembered. I then installed OpenSolaris on the box (onnv_109) and the install screens there screamed. The UI was the same, the exact same series of screens, but the overall response level was much faster.

I've now recommissioned the machine name ultralord in my home domain.

Lisa Week has provided a synopsis of the Connectathon 2009 talks (of which most have a slide deck here). Note that Lisa's notes are the only record of what Bruce Fields presented. ;->