Subject: [nfsv4] NFS/RDMA for Linux: client and server update release 7

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 01 Dec 2006 17:57:21 -0500

Network Appliance is pleased to announce release 7 of the NFS/RDMA
client and server for Linux 2.6.18. This update to the August release
fixes known issues, improves usability and server stability, and supports
NFSv4. The code supports both Infiniband and iWARP transports over
the standard openfabrics Linux facility.

<http://sourceforge.net/projects/nfs-rdma/>

<http://sourceforge.net/project/showfiles.php?group_id=97628&package_id=213593>

This code is functionally similar to the previous RC6 release, with many
bugfixes and performance improvements applied. The client and server
now use port 2050 (instead of overloading the standard NFS/TCP 2049),
pending further discussion and official assignment as proposed in the most
recent IETF working group meeting. An alignment issue leading to performance
impact on IA64 architectures has been corrected in the server. Extensive
further testing on Infiniband and iWARP was performed and (for example)
this NFS/RDMA code was demonstrated running Oracle 10g Reliable Application
Clusters at SuperComputing 2006 last month.

A full list of bugs resolved is available at the project's tracking page:

<http://sourceforge.net/tracker/?group_id=97628&atid=618583>

We welcome protocol comments, implementation comments and user
experience, directly or on any of the above mailing lists.

Tom Talpey, for the NFS/RDMA project.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 01 Dec 2006 21:00:30 -0500

At 06:12 PM 12/1/2006, Roland Dreier wrote:
>What is the status of moving this code towards merging to the upstream kernel?

For the client there are two main prerequisites, both in the RPC layer
and both in progress. One is the completion of the RPC transport switch
merge, mainly the ability to load as modules. The second is a new mount
syscall api, to allow transport-specific arguments to be passed in. We
have a temporary solution for that at the moment. When these two are
in place, the client is ready to consider merging.

The server actually doesn't have these dependencies, but it does need
to be updated to match the new code in 2.6.19 which raises the maximum
rpc payload size, and some additional hardening/improvements which we
found in code review. We're waiting to complete this work, which hopefully
will be this month.

Bottom line, we can put it on the table soon.

Tom.