NFSv4 Working Group Meetings @ 48th IETF Pittsburgh --------------------------------------------------- Reported by Brent Callaghan Monday Session (2 hours) -------------- Document editor, Spencer Shepler, began by describing some of the features of the NFSv4 implementation RFC that he is working on. The purpose of this Informational RFC is to make information available to help implementors of the protocol. This information isn't strictly necessary to describe the protocol, and would add unnecessary bulk to the NFS version 4 protocol specification. As an example of content, Spencer mentioned: - Filehandle construction Suggested content for persistent and volatile filehandles to follow correct semantics. Tradeoffs between persistent and volatile filehandles. Suggestions for how clients can recover from filehandle errors. - Internationalization NFS version 4 opens up file naming to any Unicode encoding via UTF8 wire encoding. Yet few filesystems support Unicode file naming. The document will suggest how to deal with this. - Stateid and Clientid How to build these ids with the correct properties and how to recover from stateid and clientid errors. - Filesystem Interfaces NFSv4 implementations have to resolve v4 filesystem semantics to local filesystems. The document will suggest how to resolve some of these semantic differences. Server implementations will also have to handle concurrent access to local filesystems from other protocols or local processes. In this case, other protocols might include NFS version 2 and 3 servers running concurrently on the same server host. File locking interaction needs particular attention. - Missing Attributes No client or server can natively support all of the 50 or more file and filesystem attributes in NFSv4. The server may need to approximate some attributes that it does not normally support, and clients need to be able to handle file attributes that may be missing on a particular server implementation. - File Migration and Replication The protocol specification describes errors and file attributes that support file migration and replication across server hosts. However, it provides little guidance on how a server might successfully implement migration or replication. The document will lay out the server responsibilities in migrating or replicating filesystems, include client options in handling a migration/replication event, and suggest client strategies in choosing an optimal replica. - Access Control Lists NFSvr4 ACLs are modelled after those of Windows NT. Other filesystems support different ACL models based on POSIX ACLs or UNIX permission bits. Mapping of ACL semantics can be challenging. The document will suggest how this can be done. Brent Callaghan gave a brief report on the recent NFSv4 bakeoff event held in Santa Clara, CA. July 11-13. This is the third event that tested NFSv4 interoperability. The first bakeoff was held October last year, and further v4 testing was seen at Connectathon in March. This bakeoff saw 7 implementations from 5 organizations. New this time was an OpenBSD implementation from the University of Michigan CITI group. Much use was made of a v4-enhanced version of the snoop packet analyzer, and a Tcl-based client called "nfsv4shell" that allowed testers to test NFSv4 operations interactively. Brian Pawlowski presented possibilities for future work if the working group is re-chartered. These include: - File Migration and replication - An SNMP MIB for server management - Name spaces described by LDAP schemas - A protocol for location of NFS services - Disconnected operation - ... He listed some requirements and issues for migration and replication: - Migration is the movement of a filesystem from one server to another in a way that is transparent to applications that are using the migrated files. - Replication is the creation of one or more copies of the filesystem. It also implies the on-going maintenance of replica synchronization, either by periodic resyncing or continuous update of all replicas. - The NFS version 4 spec does not define the protocol used to move or synchronize data between servers. Although this provides system administrators with some flexibility, it does not promote the construction of a robust migration or replication protocol. Current protocol for migration and replication are AFS/DFS, UNIX rdist and the rsync command. - There are some difficult problems in implementing migration and replication: - Propagating updates efficiently - Minimizing client disruption - Atomicity guarantees - Replica integrity - Read-only vs read-write replication (write replication is much harder) - File level vs block level replication - Multi-platform support. Brian concluded with an interactive discussion on future work topics. He suggested that the working group could be re-chartered to cover a migration/replication project and suggested this as a simpler option to the alternative of winding up the group and forming a new one. A risk with pursuing this additional work is that it might drain resources from the on-going standards-track work to take NFSv4 implementations to draft. However, given the time it takes to take a new protocol to the point at which it can be implemented, there is likely little overlap in effort. Other projects that could be included in a re-charter include an SNMP MIB to promote interoperable server management and a name space project that could yield an implementation document for naming. There may be some interest in a disconnected operation project, though this may be just an implementation issue, and may not need the direct attention of a working group. Tuesday Session (1 hour) --------------- Brian Pawlowski lead an interactive discussion on the requirements of a file migration and replication protocol. There are some sticky issues with file migration: it is difficult to migrate or replicate files with a consistent fileid attribute. Other file attributes could be difficult to migrate or replicate, particularly across heterogeneous filesystems. Atomicity guarantees may require filesystem support of snapshots. He provided an example of file migration in DFS. First, a filesystem operation creates a read-only clone of the fileset to be migrated. While this cloned fileset is moved, the read-write primary continues to be updated. In a second phase, the primary is locked briefly to all update traffic while the updates since the clone operation are moved. When the updates have been moved, the clients are switched atomically to the fileset at the new location. Clients never see a partially migrated fileset, the final atomic switch is not done if there are any errors. Although this method of migrating filesystems is very efficient and convenient, it does require a lot of support from the server's filesystem, e.g. the ability to create copy-on-write clones, and to identify and move updates to the clone. The rsync protocol (see www.samba.org) provides an efficient file-level protocol for synchronization of file updates between two filesystems over a TCP connection. It handles recovery from failed synchronization and can detect and resolve file byte-range insertions and deletions. It provides no support for atomicity. Brian built a list of requirements for file migration/replication: - The protocol should be efficient and restartable with the ability to update replicas incrementally. - It should be file-oriented, rather than block-oriented as in mirroring protocols. - It should emphasize correctness in providing atomic failover/migration from the client's point of view, and guarantee that replicas are correctly synchronized. - The protocol should express file-level changes in compact form and work well over limited bandwidth. - It should be secure from attacks that steal or change the data. - It needs to be scalable to huge filesystem, yet handle small filesystems efficiently. - It must handle multiway replication and provide for conflict resolution in changes between replicas. - Some discussion on how to deal with transfer of filesystem state like locks. According to Mike Kazar, AFS/DFS transferred file locks as well. This may be difficult to accomplish in an atomic and heterogeneous way though. A simpler strategy was suggested: just handle the migration/failover event as if the server had rebooted and let clients re-establish state themselves. Further discussion on the topic will be left to the mailing list. Simon Cooper of SGI raised some concerns on NFSv4 security in the final minutes of the meeting. He said that the RPCSEC_GSS RFC leaves security negotiation up to the higher-level protocol, yet NFSv4 doesn't describe security negotiation outside of GETSECINFO. He suggested that it is inadequate since it does not require a secured connection between client and server. Given the time constraint, further discussion will be moved to the NFSv4 mailing list. ------------------------------- The slides from the meeting can be viewed at: http://playground.sun.com/pub/nfsv4/presentations/ietf48 ------------------------