Apologies for late posting. ---------------------------------------------------------------- NFS Version 4 (nfsv4) WG Meeting Minutes - DRAFT Tuesday, July 11, 2006 - 09:00 - 11:30 Montreal, Quebec, Canada ----------------------------------- Minutes compiled primarily by Lisa Weeks (THANKS! Lisa!), some editing by beepy. pNFS summary from Garth Goodson with additions by Lisa Weeks (thanks Garth!) o Welcome and Introduction (Pawlowski) Agenda bash etc. BLUE SHEETS NOTE WELL Agenda bashed and noted well. David Black announced that pNFS blocks draft converging for last call in a month or so. (Nothing to discuss in the meeting). o IPR disclosures (beepy) https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=721 What is the impact of the disclosure? * Disclosure was on the published RFC and mentions previous versions of NFS. This is not a major deal. We can't really do anything about this....it is a RFC * There were no disclosures on the Individual Drafts. Determine if a disclosure on the Drafts will be forthcoming. Make sure we don't get into a similar case when 4.1 is published. Area director needs * The wording of the IPR say that "For reason of implementing the RFCs, the license is free". * The working group needs to determine if they want to do to the specification in order to get around the IPR. And also decide how they want to move forward. * Have we formally asked for a specific explanation of the IPR from IBM? The IPR is stated so vaguely that it is hard to know what it actually covers. beepy owns action item to determine working group action, if any, with regard to the IBM IPR disclosure against RFC 3530 for the current work in progress and publish a plan. o NFS/RDMA Last Call preparation (Talpey) Tom Talpey reported on the updates to the problem statement and NFS-RDMA drafts. Wants to move independent drafts to working group last call. (NFS-RDMA work dependent on Remote Direct Data Placement WG work). David Black gave a brief status of RDDP drafts moving in three pairs: - applicability - security - RDMAP and DDP going to last call, open issue closing in a week, this week or next... - SCTP and ADD IP dependency... will effect RFC Editor release - no IESG approval issue but may slow down doc approval Back to NFS-RDMA - Talpey reported there are two implementations: Linux - NFSv2,3,4 tested and passing Cthon, etc - Tested over infiniband, iWarp OpenSolaris client server - NFSv3 tested and passing Connectathon Linux client, Solaris server interoperating. o Multi-server Namespace Functionality (Noveck) Noveck rewrote migration/replication chapter originally in RFC 3530. Takes discussion from a single server name space to multi-server name space issues (replication, migration and referrals). - Eliminated contradictions - Clarified stuff - Cleanup and corrections from ID (draft-noveck-nfsv4-migrep-00) Referrals are now explicitly mentioned and discussed. Uses draft-ietf-nfsv4-referrals-00 approach. Referrals document applies to 4.0 and should be taken forward as Informational RFC approval? Some more details (see slides also) *Options when effecting fs transitions * New attributes; -fs_absent: simple boolean "is it here?" - fs_locations_info: fs_locations on steroids - fs_status: migration/replication fs_locations_info: - to deal with todays problems and the future's - more replicas - more different kinds of replicas - more knowledge helpful to client more ability for server control - more support for cont... (on slides) - Go into the different type of replicas (i.e. there are differences between two paths to the same server and two paths to different servers) * Deleted stuff due to perceived lack of interest... There was a major back and forth regarding what it means to be a replica, and how they are consistent, and how a client knew when one "object" was a replica of another. Replicas are identical data. Slightly different is probably not where we want to go. Stale bit issue... David Black brings up. This discussion will be taken to the working group alias for resolution. Bring back up transparently splitting a FS. Get IBM implementation experience... Mike Kazar is a living fossil... :-) (note to have Mike review this section of the draft from an AFS experience perspective) Status: Mostly ready for thorough review o pNFS Issues (Goodson) Brief summary of discussion around open issues at IETF meeting. * Issue #21: CB_SIZECHANGED - Discussion around whether we really need it for files and objects. Came to the conclusion it is only really necessary to close the hole between WRITE COMMITs and followed by READs. LAYOUTCOMMIT and SETATTR should extend the files on the DSs so it isn't an issue there. It also does not currently violate open-close consistency. - People are still confused about what it does in the block's case. David Black gave an example that helped some understand, others not. I think it needs to be made very clear how this is not an optimization but rather required for correctness. beepy noted the issues seem to lay around semantics of Layout COMMIT and EOF and client "consistent" view. beepy believes he cautioned at this point that the WG was not revisiting issues of overall data consistency semantics of NFS - and that the resolution here was to drive towards correctness of the pNFS additions. For the record: in the panasas fs, they used the push model and it worked better than the pull model. * Issue #40: DS and MDS w/different security mechanisms - No disagreement on Mike Eisler's proposed text - only applicable to files based. - Seems like Andy has comments brought up on mailing list, will close once discussion has completed - and declare consensus. * Issue #55: Attribute for when to write through MDS - Seemed to be general agreement that this sort of "hint" represented as an optional attribute would be useful - Options based on size of writes; offset in file Garth posted a proposal on two ways of doing this. Only heard back from Mark Eshel. Would like more feedback before adding it as text... Benny thinks we need more research (not another attribute but an operation). - We have examples from two existing systems that say that this is a good thing. - Garth will pick structure and repost proposal - Benny would like something more dynamic in nature (to reflect changing workloads); it was agreed a proposal on this could come after we have closed on current attribute * Issue #57: Private layout range - Agreed that we will have a private layout range (high-bit set) - Agreed that we will use IANA registry for layout type definitions - Agreed that we will require a RFC for new layout types IANA the layout types - mechanical... RFC 2434 has some default policies... Figure proposal - expert review... Publish RFC to get a layout type... - Garth will write up this section and close the issue * Issue #58: Layout return/recall flags - Some discussion over RETURN_ALL/RECALL_ALL flags New flags: FSID returns, RETURN_ALL, RECALL_ALL - Problem of Clients and servers getting out of sync: when they get out of sync, we have a reasonable ability to get back in sync. Wasn't clear if this is really necessary to get client and server back in sync - Will attach Marc Eshel's proposal of flushing client device ID cache to RETURN_ALL or FSID returns - Benny will update current proposal and repost for more discussion * Issue #61: Lingering writes - No objections, will close using posted paragraph * Issue #69: File-layout striping structure - Save space on the clients for layouts that contain pretty much the same information. Makes device in the file layout case more complex, but it is just an optimization. - No real disagreement - Issue was raised that these simple/complex device IDs might be useful in a generic sense (across all layouts); will revisit this once we have it defined for files - Garth will update proposal with specifics and repost Other discussion: Mark Eshel would like to revisit client-side device flushing op. Upon RETURN_ALL, the server has no responsibility for the server to keep the same deviceid mapping. Need to have clear text that describes layout return meta op (it was suggested that we need pairing of recall/return layouts to facilitate correctness) There is general agreement and just needs to be more discussion. o NFSv4.1 I-D schedule and work item planning (Shepler/Noveck) Went over specs in progress. Reconcile with charter and milestones, deliver to the ADs in toto. Off cycle spec review with Bakeathon. Dave Noveck presented an end game strategy of dividing up the 4.1 spec editorship into pieces under overall editing done by Spencer to move a bit more quickly on the large document. Email describing the specific responsibilities and ownership going forward to be sent out. - Three editors and Sourceforge notion to be worked out amongst Eisler, Shepler and Noveck... o pNFS Objects (Halevy) See slides - they were fairly complete and descriptive of current status and issues with recommended resolutions. No actions to be taken. (Apologies to Halevy - we seriously ran out of time and a bit over and cut his presentation time down to almost nothing). o NFSv4.1 last call rules - discussion (beepy + ADs) Need to put the bounds on what is going to be included in the NFSv4.1 draft. We will be switching to having more scrutiny based on the issues opened. We are "closing down"... Implementation experience requirements: First we will get the list of what people will bring to the Bakeathon then we will have the discussion about what increases our comfort in knowing the specifications are valid. o Sept 2006 Bakeathon Planning (Trond) Trond brought up the need for a Bakeathon to be held at the University of Michigan in September to test NFS Version 4 and proposed 4.1 extensions (including pNFS). Trond is to take to WG alias driving the features to be tested. beepy mentioned possibility of final spec issue review and resolution via interim meeting overlapping Baekathon. o Adding Data Retention attributes (Eisler): 2 attributes for data retention. retained (boolean) retention date Intent that this is mandatory, but it they are "Recommended" attributes... David Black is concerned that the attributes are moving in parallel to the SNIA FIxed Content Aware Storage WG. beepy mentioned that this is new work not currently in draft. Discussion to be taken to the list. o Charter / Milestones (beepy, Shepler, ADs) Charter hasn't been updated to cover the pNFS discussion, Beepy will give the ADs a paragraph. ADs say: This group is clearly doing lots of technical work, but publications are low. Need to close the door on saying that anything NFSv4 is on the wg's charter. Have your charter say what is in scope. Then anything outside of that will require a re-chartering. This group has a history of picking up a lot of individual drafts and rolling them into a larger document. Usually, each working group has to have milestones for all working group items. Spencer taking AI to reflect the milestones for the drafts in progress. Quick discussion on current drafts: 1.) nfsv4.1 draft 2.) pNFS blocks draft 3.) pNFS object draft 4.) 3 RDMA drafts moving toward WG last call 5.) Referrals draft (pulled into 4.1) - Referrals would be informative. 6.) ACLs draft (pulled into 4.1) - ACLs would be normative. 7.) Channel bindings draft - will be published as a individual submission. Security ADs don't feel like it should be a Security WG item. Will be last called soon. Lars will touch base with the Security ADs. 8.) Discussion of Mapping NFSv4 to POSIX-draft ACLs Come up with milestones/schedule for each of the authors. Send update to IESG. The WG needs to relate each draft to a charter item. AD: Wants charter update and milestones produced together. Make sure not to forget about byte-range delegations, SPKM (still doesn't have a home) o ACLs (Falkner): Take action to keep responding to Andreas on ACL issues. Beepy to figure out how to converge. ACL document pertaining to NFSv4.0 should be Informational RFC (?) This doesn't have to be decided right now. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4