NFSv4 Interim Working Group Meeting Feb 18, Feb 19 - Sunnyvale CA Agenda - Feb 18 --------------- Intro/Blue Sheets/Note Well Agenda Bashing Working Group status and interim meeting goals NFSv4 bis issues Userid Translation in AUTH_SYS Environments LEASE_MOVED error handling RFC 5664 pNFS Errata Simple and Efficient Read Support for Sparse Files FedFS Domain Roots NFSv4.1 pNFS Open Issues pNFS LAYOUTCOMMIT optimizations Agenda - Feb 19 --------------- Intro/Blue Sheets/Note Well Agenda Bashing LAYOUTCOMMIT Remaining Issues from pNFS issue discussion Server-Side Copy Implementation Experience NFSv4.2 Structure and Content pNFS File Servers Implementation Strategy pNFS over IPv6 Performance Related Issues of NFSv4.1/pNFS Secure NFS in 4.x Multi-layout pNFS server support FedFS implementation issues ====================================================================== Opened meeting with normal Note Well statement and blue sheets. ---- Spencer briefly covered the current status of the working group and current charter items. Current working group charter is maintenance with the exception of FedFS and FedFS is coming to the maintenance portion of its lifecycle. The goal of the interim meeting is to close on long, outstanding issues; these issues cover the RFC3530bis work along with NFSv4.1 issues that have been found through implemetnation experience. Once those agenda items are cleared, NFSv4.2 structure and content will be discussed with the intent of drafting a charter update such that NFSv4.2 work is included. Timeline will be to discuss the draft charter with Area Director during Prague meeting. Close on issues and move forward. ---- Next up was the review of the remaining RFC3530bis issues as identified by Tom. The minutes will not reflect the desposition of these items. Please refer to the detailed notes published to the working group alias. http://www.ietf.org/mail-archive/web/nfsv4/current/msg08996.html All items were discussed and reached consensus during the meeting. (editor's note: I-D will follow normal last call process; this will allow for working group review of final set of changes for RFC3530bis) ---- UserId translation issues RFC3530 defined use of strings to identify users and groups for file and directory attributes. There has been deployment issues with NFSv4 because of translation issues from commonly used numeric user/group ids and the string based identifiers. Tom H. wanted to bring that discussion tot he working group in an attempt to find common ground on clarifications for NFSv4 to simplify NFSv4 deployments. It was noted that RFC3530 allows for a method of user/group identifiers to be simple string representations of the numeric ids without the use of the @domain suffix. Unfortunately, the language in the RFC is very discouraging and some implementations have avoided the use of string numeric IDs because of it. The agreement of those in attendance was that if the issue was a deployment blocker and if, after this much time in the field, methods have not been found to work around the deployment issues then the language should be relaxed. In summary, for AUTH_SYS environments, it is acceptable to use stringified numeric representations for user and group identifiers. This will allow for NFSv3 to NFSv4 transitions for those environments that are not deploying Kerberos. Suggestions will be made to allow for configurations of servers and clients to adapt behavior for those environments that would prefer the use of @domain suffix. Will be included in the RFC3530bis work ---- LEASE_MOVED error handling Trond reviewed the issue in having the client clear a LEASE_MOVED error from the server. The server is supposed to keep returning the LEASE_MOVED error until it is received by the client. The client doesn't have a method, in NFSv4.0, to identify which of the filesystems have moved. It must then query each one being access to clear the error. The conclusion was that both types of clients (those that support and do not support migration) must query the server when LEASE_MOVED is received. The query would be of the form: PUTFH + GETATTR(fs_locations) + RENEW This sequence allows the client to obtain the location information for each of the filesystems in question. The RENEW operation allows the server to identify the client such that it knows which clients are querying for which filesystems. Tom Haynes will work to incorporate into 3530bis ---- RFC 5664 pNFS Errata Benny reviewed the implementation experience for 5664 and what issues arose with the document. There seem to be a short number of issues in the text that need to be corrected. The corrections do NOT require over-the-wire format changes. However, there are changes that are impactful (e.g. what algorithm to use for RAID-6 support). Spencer suggested that the errata text be sent to the working group first. This will allow for comment/feedback before the items are submitted to the RFC errata pages. This will allow for faster approval/clearance when the errata are formally submitted. This review will also allow for a final decision of whether a 5664bis should be done to clean up the issues. ---- Simple and Efficient Read Support for Sparse Files Bruce reviewed his proposal and there was much discussion. There is interest in seeing this support in NFSv4.2. However, there was some concern about details of the proposal. The detailed notes of the meeting capture that discussion. Dean agreed to rework his proposal to leave the basics in place given that consensus seemed to be moving towards a simple mechanism that allowed for effective reading of sparse files. Dean to update his I-D. ---- FedFS Domain Roots With the completion of the base FedFS work, Chuck presented 3 open issues to solicit feedback. First was the issue that FedFS provides NFSv4 clients access to the root of the namespace and that portion of the namespace is a collection of referrals. This varies from AFS where the client was able to "walk" into a writable version of the filesystem. With FedFS, the cilent would have access to the writable portion of the referral portion of the tree. Is that desired or useful? With the use of DNS SRV records and their weight, the client is vulnerable in the event of a server reboot. The client may make a hard reference to that server and thus be vulnerable if things change. Current state is that NFS is the only protocol supported; James pointed out that the intent was to allow for extensibility such that SMB could be included in the future. ---- NFSv4.1 pNFS Open Issues Prior to the meeting, Dave Noveck had captured the set of outstanding NFSv4.1/pnFS related issues into a single document. This document captured the choices available to the group. This document is what was reviewed during the meeting. The original email/document resides here: http://www.ietf.org/mail-archive/web/nfsv4/current/msg08938.html The detailed meeting minutes capture the discussion and invidual resolution of the items. On the first day, a small number of details were not discussed and we picked those up on the second day. A brief summary is that a choice was made for all items and the resolutions will be worked as needed. ---- pNFS LAYOUTCOMMIT optimizations One of the major issues left unresolved is the use of LAYOUTCOMMIT. Is the client required to use it? Under what conditions should/must be used? What do server want to see or not see with respect to LAYOUTCOMMIT? What is the relationship with classic NFS close-to-open cache consistency semantics. These were the issues touched upon during the discussion. The outcome of the discussion was the realization that current operations and return values could be used to communicate when the client was required to use LAYOUTCOMMIT. Mike volunteered to capture the results and presented ideas on the second day. We now have a simple table that describes the use of WRITE-to-data-server return results, what COMMIT does at the data server and meta data server. Here the summary table. Mike's presentation should be consulted for further context. Value of NFL4 WRITE to Meaning of Meaning LAYOUTCOMMIT UFLG COMMIT Data COMMIT to of COMMIT needed? THRU MDS bit Server Data to MDS in layout returns Server ========================================================================= Not set UNSTABLE4 DATA_SYNC4 Nothing YES Not set DATA_SYNC4 Nothing Nothing YES Not set FILE_SYNC4 Nothing Nothing NO Set UNSTABLE4 Nothing FILE_SYNC4 NO Set DATA_SYNC4 Nothing FILE_SYNC4 NO Set FILE_SYNC4 Nothing Nothing NO -- Note that client can always demand FILE_SYNC4 or DATA_SYNC4 in WRITE's arguments ---- Server-Side Copy Implementation Experience Pranoop provided information about the Netapp prototype of the server-side copy functionality as described in the I-D. Good experience gained from the implementation and the details of that are in the presentation. ---- NFSv4.2 Structure and Content This item captured aspects of timeline, form, and content for NFSv4.2 with the intent of driving an update to the working group's charter. The summary of the discussion was captured and sent to the working group and replicated here. ============= From working group email =================== At the interim meeting, we discussed NFSv4.2. This message is a summary of that discussion, a plan for next steps, and a further determination of rough consensus within the broader scope of the WG alias. Our current working group charter includes maintenance of NFSv4.0, NFSv4.1, and the RPC/XDR protocols. With completion of the Federated Namespace I-Ds, that charter item will move to maintenance. The discussion and concensus at the interim meeting was to add a working group charter item for the development of NFSv4.2. The group reviewed a set of options for how best to manage NFSv4.2 content and timeline. The eventual conclusion was to focus NFSv4.2 as a time limited deliverable. The premise is that solid proposals exist today for NFSv4.2. Setting a deadline for NFSv4.2 delivery will act as a forcing function to complete existing proposals and if other less mature proposals reach a similar level of maturity, they can be included in NFSv4.2 as well. The timeline chosen during the meeting was 1 year; for example, NFSv4.2 ready for working group last call by March 2012. The next topic was what physical form NFSv4.2 would take. An NFSv4.2 RFC will not document the entire protocol. NFSv4.2 will build from the NFSv4.1 RFC and note only the functional additions or semantic clarifications required to build NFSv4.2. NFSv4.2 may or may not be multiple RFCs. That determination will be made later based on content scope and document size. The discussion then moved to content. The highest priority items are bug fixes for NFSv4.1; these are more than just errata. The current bug list is: - pNFS Access Permissions Check (has I-D) - LEASE_MOVED callback - Change attribute semantic description (I-D needed) So, these bugs may take the form of new operations or semantic changes that require the minor version update. Note that NFSv4.2 will abide to RFC5661's Minor Version rules as defined in section 2.7. Those in attendance discussed all of the outstanding functional proposals -- those in the form of personal I-Ds at the time of the meeting. The intent of this discussion was to determine level of proposal completeness and current energy/interest. Of all proposals, the following were considered to be most appropriate for NFSv4.2 at this time. - NFS Server-Side Copy - Simple and efficient read support for sparse files - NFS space reservation operations - RPCSEC GSS v3 (needed for NFS Server-Side Copy) The goal of identifying the list above is two-fold. First, provide direction to those in the working group as to where our collective energy should be placed. Second is to have content for the necessary working group charter update. As mentioned above, this is not meant to be exclusionary. Other work items may be included in NFSv4.2 as well if the required level of interest and maturity are reached. To that end, the following set of proposals had interest but level of maturity was less than desired. There is potential for NFSv4.2 inclusion but these will not be the initial focus items. - NFSv4.2 Unstable File Creation - NFSv4 pNFS Back End Protocol Extensions - Extending NFS to Support Enterprise Applications - Storage Control Extensions for NFSv4 - Fadvise (from original NFSv4.2 requirements -- need I-D) Finally, the next set of proposals seem to lack both energy and maturity. - MAC Security Label Support for NFSv4 - NFS Pathless Objects - Storage De-Duplication awareness and sub-file caching in NFS - Metadata striping for pNFS Beepy and I have asked Tom Haynes to be the editor of NFSv4.2 and he has accepted that responsibility. Beepy and I will be working with our area directors on the required text and charter milestone updates for the NFSv4 working group. We will cover the detail of the charter update during our meeting in Prague. The goal is to provide our area directors the insight and detail needed to represent our work with the remainder of the IESG. There is an item that falls outside of NFSv4.2; it is of interest to our working group but spans multiple groups within the IETF and an exact home is unclear. I am referring to the NFSv4 Multi-Domain Access drafts that Andy Adamson has been working on. I am going to propose that the NFSv4 WG take this on as a charter item as well and will include the item into our charter update. ============= End of working group email =================== ---- pNFS File Servers Implementation Strategy pNFS over IPv6 Performance Related Issues of NFSv4.1/pNFS Secure NFS in 4.x Multi-layout pNFS server support FedFS implementation issues Sorin presented a number of items that were discussed at the last NFSv4 bakeathon. These are in one presentation. The one of immediate interest was the "pNFS block signature/disk protection" portion of the discussion. Sorin's action was to capture the issues in an I-D such that a guide for further discussion would be in place. The other item of interest was the communication that SPEC is taking on the development of a benchmark for the measurement of client and server and this may be of interest to those in the NFSv4.1/pNFS community. ---- End of meeting.