From Daniel.Ellard at netapp.com Fri Jan 4 07:36:10 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Fri, 4 Jan 2008 10:36:10 -0500 Subject: [Federated-fs] tentative federated-fs plan for the next few months Message-ID: Here's the current plan for the federated-fs discussion. I see the major goals for the next few months are to hammer out the remaining details of the NSDB protocol spec in time for the next IETF NFSv4 WG meeting, and have a solid candidate for the admin spec. Your input is welcome. Conf call times/dates are tentative; please let me know if you have a strong preference for a different time. All the conference calls use the same number: 1-888-765-3653 # 6206056 1/8/08 4:00pm EST - Federated-FS conf call This may be canceled because there's no new draft to discuss. My apologies. 1/11/08 - New personal drafts: a. Refresh of the reqts doc (renamed so that the automatic tools for bringing these to the attention of the right WG folk). b. First draft of the NSDB protocol spec (which is derived from the most recent draft of the fedfs spec, but REMOVES the admin stuff). 1/17/08 2pm EST - Federated-FS conf call 1/28/08 4pm EST - Federated-FS conf call 2/4/08 - New drafts: a. Second draft of NSDB protocol spec. b. First draft of admin protocol spec. 2/11/08 4pm EST - Federated-FS conf call 2/21/08 2pm EST - Federated-FS conf call 3/3/08 4pm EST - Federated-FS conf call 3/9/08(?) - IETF NFSv4 WG meeting in Philadelphia -- Daniel Ellard, Ph.D. Advanced Technology Group, Network Appliance, Inc. From Daniel.Ellard at netapp.com Mon Jan 7 11:12:35 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Mon, 7 Jan 2008 14:12:35 -0500 Subject: [Federated-fs] Any agenda items for today? Message-ID: Unless someone has any items for the agenda today, I'm going to cancel the conference call scheduled for this afternoon. I will send out a new draft later this week and reschedule the calls to give people a chance to review it. -Dan -- Daniel Ellard, Ph.D. Advanced Technology Group, Network Appliance, Inc. From daniel.ellard at netapp.com Fri Jan 11 03:28:58 2008 From: daniel.ellard at netapp.com (Daniel Ellard) Date: Fri, 11 Jan 2008 06:28:58 -0500 Subject: [Federated-fs] New drafts of the federated-fs specs Message-ID: I uploaded two new drafts to the IETF web site on Wednesday: draft-ellard-nfsv4-federated-fs-00 (https://datatracker.ietf.org/drafts/draft-ellard-nfsv4-federated-fs/) draft-tewari-nfsv4-federated-fs-protocol-01 (https://datatracker.ietf.org/drafts/draft-tewari-nfsv4-federated-fs-protoco l/) Despite their low version numbers, these are really updates to previous documents, renamed and reformatted to match the new plan on how to organize the docs. The first (draft-ellard) is a minor update to the requirements doc draft (which expired in December). The second (draft-tewari) is an update to Renu's protocol spec to split out the admin sub-protocol from the NSDB (resolution) sub-protocol. This document focuses on the NSDB protocol. The reason for this split is that we feel that the NSDB protocol is considerably farther along than the admin protocol -- these protocols are at different stages of development and it makes sense to separate the discussions. I'll upload a draft of the admin protocol as soon as the reformatting is complete. The next federated-fs conf call will be 1/17/08, 2pm EST, 1-888-765-3653 conference number 6206056. -Dan -- Daniel Ellard, Ph.D. Network Appliance; Advanced Technology Group From Daniel.Ellard at netapp.com Mon Jan 28 11:54:31 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Mon, 28 Jan 2008 14:54:31 -0500 Subject: [Federated-fs] federated-fs conf call today Message-ID: There will be another federated-fs conference call this afternoon, at 4pm EST, dial-in number 1-888-765-3653 # 6206056. The original goal was to talk about the draft of the admin protocol this afternoon, but I'm still writing the draft, and there are a bunch of things that I don't feel like we've discussed enough to say the draft is strong yet. So let's talk about some of those things... To refresh everyone's memory, the admin protocol is the protocol that a federation member administrator uses to make federation-oriented requests to an individual server. I would like to propose some important changes to the current protocol, which I now believe is broken (although I admit I originally argued for it). In the current protocol (as seen in the earlier drafts) some of these requests are to change the state of a server in some way (e.g., create a junction) while others are only to query the state of a server (e.g., find the FSN that should be used to refer to a given path). The former class of requests are meant to be performed by the administrator on servers under its administration (i.e., within the same federation member) while the latter may be used more widely. There might be limitations on who can query servers in the system -- that's another topic for discussion -- but for now let's assume that anyone can query any server they can reach. The first (and perhaps messiest) operation the admin performs in the current, proposed protocol, is creating junctions to stitch together the namespace. In the worst case, we're starting from a blank slate, and the target of the link does not already exist in the namespace. We need some way to identify it, and the current notion is that such filesets are identified initially by a concrete address, via the following protocol: The "source" admin wishes to create a junction from a fileset under its control to a fileset that it can reach, using ordinary NFSv4, as hostname:path. (there may be additional parameters, but this is the minimal case) 1. The admin sends a query to host hostname, asking it for the FSN of the fileset rooted at hostname:path. 2. Host hostname may refuse, or the path may be invalid, etc. If it is valid, and the hostname knows the FSN, it returns the FSN. Otherwise, if the host wishes for the protocol to succeed: 2a. Host hostname creates an FSN for hostname:path by choosing an NSDB location, creating an FsnUuid (or having the NSDB location choose one), and registering the resulting FSN with the NSDB. 2b. If the fileset is replicated, then the host registers all other instances of the same fileset as FSLs for that FSN. 2c. The host notes the new FSN as belonging to that hostname:path, and returns it to the admin. I think that this protocol is problematic in several ways, primarily in steps 2b and 2c. The problem is that the host must somehow know the FSN of the filesets it exports (if they already exist) and the host must also have some way of finding all the replicas of any fileset it hosts. The final problem is that there is a potential for a race condition in step 2a: if this protocol is executed concurrently on two replicas of the fileset, we may potentially end up in a state where the same fileset has two FSNs -- and no method to tell them apart or banish one. There are ways to extend the protocol in order to add more centralized control, but I think the result would be awkward and complicated. The fundamental problem is that we are asking the NFS servers to shoulder some of the burden of managing the global namespace. I think this should all be pushed back onto the NSDB. So here's my new proposal: junctions can be created ONLY to FSNs, not by reverse-resolving FSLs. Filesets MUST be registered as FSNs before they can be the target of a junction. (The exact procedure for accomplishing this may be host-dependent.) This means that the target host is never involved in creating a junction, so there is no need for what effectively was server-to-server communication via the admin. -Dan -- Daniel Ellard, Ph.D. Advanced Technology Group, Network Appliance, Inc. From Daniel.Ellard at netapp.com Wed Jan 30 12:19:12 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Wed, 30 Jan 2008 15:19:12 -0500 Subject: [Federated-fs] conf call scheduling changes necessary? Message-ID: A number of people have been unable to attend the recent federated-fs conf calls because of scheduling conflicts. I'm willing to change the meeting day/time if that will increase participation. Four proposals on the table are: - No times work better than the current schedule; keep going with the current schedule. - Remove the Monday meetings and instead meet weekly, every Thursday at 2pm EST, starting 2/7/08. - Move the Monday calls (every third week, more or less) to one hour earlier (3-4pm EST). - Move the Monday calls to Tuesday at 3pm EST. If these all sound unworkable, feel free to propose another time... Thanks, -Dan -- Daniel Ellard, Ph.D. Advanced Technology Group, Network Appliance, Inc.