From daniel.ellard at netapp.com Tue Aug 5 19:54:58 2008 From: daniel.ellard at netapp.com (Daniel Ellard) Date: Tue, 05 Aug 2008 22:54:58 -0400 Subject: [Federated-fs] New drafts of the IETF documents Message-ID: I uploaded three new versions of the drafts today: The requirements document: https://datatracker.ietf.org/drafts/draft-ellard-nfsv4-federated-fs The "NSDB protocol" document: https://datatracker.ietf.org/drafts/draft-tewari-nfsv4-federated-fs-protocol And the server-admin document: https://datatracker.ietf.org/drafts/draft-ellard-nfsv4-federated-fs-admin/ Enjoy, -Dan -- Daniel Ellard, NetApp From Christian.Bandulet at Sun.COM Thu Aug 7 07:51:28 2008 From: Christian.Bandulet at Sun.COM (Christian Bandulet - Principal Engineer) Date: Thu, 07 Aug 2008 16:51:28 +0200 Subject: [Federated-fs] Federated FS, pNFS, NFSv4.1 referrals.... Message-ID: <489B0BF0.6060501@sun.com> Daniel, I had a look at: http://tools.ietf.org/id/draft-ellard-nfsv4-federated-fs-01.txt I am still not sure what the difference of federated FS is compared to pNFS or NFSv4.1. referrals. I guess that pNFS and NFSv4.1. referrals should also work across heterogeneous file server, right? Is it correct that a NFSv4.1. client which requests a file from server A will get back a referral structure instead of the file itself. the client then in a second step has to contact the right file server whose name will be part of the referral structure received from server A? In a federated FS would server A be a kind of proxy - i.e. the client will receive the requested file from server A no matter whether it is really physically hosting the file? i.e. server A can get the file from server B and deliver it to the client? Is federated FS e.g. about unifying several pNFS-built global namespaces to a single super-global namespace? thanks for you patience, Christian -- ==================================================================== Christian Bandulet Sun Microsystems Principal Engineer Amperestr. 6 Data Management Ambassador D-63225 Langen Germany Tel.: +49-6103-752-142 (Sun: x65142) Fax.: +49-6103-752-299 mailto:christian.bandulet at Sun.COM http://www.sun.com ===================================================================== Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering ===================================================================== From ellard at netapp.com Thu Aug 7 08:30:12 2008 From: ellard at netapp.com (Daniel Ellard) Date: Thu, 07 Aug 2008 11:30:12 -0400 Subject: [Federated-fs] Federated FS, pNFS, NFSv4.1 referrals.... In-Reply-To: <489B0BF0.6060501@sun.com> References: <489B0BF0.6060501@sun.com> Message-ID: <489B1504.7030103@netapp.com> Christian Bandulet - Principal Engineer wrote: > Daniel, > > I had a look at: > > http://tools.ietf.org/id/draft-ellard-nfsv4-federated-fs-01.txt > > I am still not sure what the difference of federated FS is compared to > pNFS or NFSv4.1. referrals. Good question. fed-fs, pNFS, and NFSv4.1 address different issues, and so instead of focusing on their differences, I think it's more informative to focus on how they complement each other. They are not competing ideas -- they augment each other. > I guess that pNFS and NFSv4.1. referrals should also work across > heterogeneous file server, right? Yes! If they don't then something is broken. The semantic and structure of these referrals are part of the protocols and should be platform-independent. If not, then fed-fs is broken as well. > Is it correct that a NFSv4.1. client which requests a file from server > A will get back a referral structure instead of the file itself. the > client then in a second step has to contact the right file server > whose name will be part of the referral structure received from server A? > One of the key differences between pNFS and fed-fs is that the client is "aware" of pNFS (the client knows, from info it finds from the server, how to piece together files from shares spread across a set of servers), while the clients don't need to know whether fed-fs is being used (although they might suspect something is up if they keep getting referrals...). fed-fs is the protocol that servers use to figure out where to refer clients, while pNFS includes a client protocol. > In a federated FS would server A be a kind of proxy - i.e. the > client will receive the requested file from server A no matter > whether it is really physically hosting the file? i.e. server A can > get the file from server B and deliver it to the client? No -- fed-fs does not proxy requests. If server A has a junction to directory X and directory X happens to be hosted on server B, then what would happen if a client of A accesses directory X is that the client would get a referral to X on B. > Is federated FS e.g. about unifying several pNFS-built global > namespaces to a single super-global namespace? That's one use case. It can be used to stitch together any kind of NFSv4 namespaces together. fed-fs doesn't care whether the underlying filesystems use pNFS or vanilla NFSv4. It only tells the servers what they need to know in order to refer the clients to the right places -- after that, it's up to the client to access the objects via pNFS or any other way. -Dan From Daniel.Ellard at netapp.com Thu Aug 7 10:54:55 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Thu, 7 Aug 2008 13:54:55 -0400 Subject: [Federated-fs] Reminder: conf call 2pm EDT Message-ID: (five minutes from now...) 1-888-765-3653 # 6206056. -Dan From ellard at gmail.com Fri Aug 8 07:44:00 2008 From: ellard at gmail.com (Daniel Ellard) Date: Fri, 8 Aug 2008 10:44:00 -0400 Subject: [Federated-fs] Notes and news from the fed-fs conference call yesterday Message-ID: First, some news. I will be leaving NetApp this afternoon, to pursue an interesting opportunity at BBN Technologies. I will remain involved in the fed-fs work, at least for the next few months, but in a reduced role (I will have a different day job). James Lentini, another member of the NetApp Advanced Technology Group and an expert in RDMA and NFS, will be taking over my fed-fs role at NetApp. There may be some other new faces (or familiar faces taking different roles) as well. If you need to contact me, please use my gmail address. My NetApp address start to fail (probably silently) in a few hours. Notes from the conf call: Attending: Daniel Ellard, James Lentini (NetApp), Paul LeMahieu (EMC/Rainfinity), Renu Tewari, Manoj Naik (IBM/ARC), Mario Wurzl (EMC). THE DEMO Manoj asked about the demo in Dublin. Not that many people got to see it, because attendance in Dublin was low. Here is a brief description: Amy Weaver demo'd a namespace implemented by several servers. I'm not sure of the final config, but in our practice runs, we had an ONTAP 8 (development version) system, an ONTAP 7 version (released) box, a Linux 2.6 box, and an OpenSolaris box (not sure of the version). The ONTAP 8 system implemented the root fileset and several of the other filesets. Only ONTAP 8 fully supports the fed-fs protocol right now, so the other servers hosted leaf filesets in the namespace. The demo system had one NSDB (for simplicity -- we've also demo'd several) and the demo was performed live, over the network, using machines located in Sunnyvale. Amy demonstrated how to create junctions and then demo'd a vanilla Linux client traversing the namespace. We're open-sourcing a version of the NSDB and a C API for it (dual license, BSD/GPL2) that conforms to the draft of the protocol from earlier this week. Because the draft is still ambiguous and underspecified in places, the code takes some short-cuts. It should be considered a proof-of-concept at most, but it could help bootstrap other implementations. We'd love to see people federating across platforms at a bakeathon or connectathon soon! PUSH VERSUS PULL If we have a replicated root fileset (and we believe we will need to), then how are changes to the root propagated from the "master" (which we believe we'll probably need) to all of the replicas? Paul had taken the position, a few weeks ago, that having the master push changes out the replica makes the most sense. Others pointed out that in a federated and distributed system, a push model is hard to implement because if a replica goes down, or something else happens that makes the state of the replica unknown to the master (possibly without the master even knowing), it can be hard for the master to know what state each replica is in, and what messages to send to bring that replica up to date. On the other hand, the replicas can keep track of what messages the have and haven't seen from the master (and/or a logical clock for state versioning) and pull the changes from the master. Either way there are complicated cases, but the observation was that in some cases, pull is really necessary, so if we need a pull anyway, let's not do both. Paul was not on the call last week, so we postponed further discussion until this week. After some discussion the consensus is that a pull model is OK as long as we can ensure that there is a way to minimize the state changes the replicas need to pull (i.e., just deltas) rather than brute-force polling. Paul and Renu are signed up to continue refining their document about how the replicas get updated. TRANSACTIONS -- NEEDED? One of the assumptions required to do simple things like update the state of the replicas is that it's possible to actually *define* the state of an NSDB at a logical moment. This seems like a simple thing, but it's not something that LDAP seems to support. Basic LDAP does not seem to have a graceful way to deal with concurrent updates to multiple, overlapping records -- no locking or transaction support. Since many "logical" NSDB operations involve multiple NSDB operations, this could make ensuring the correctness of the NSDB operations difficult or impossible. We discussed a strawman proposal to implement vector clocks (one scaler per admin) but the feeling was that it would be clunky at best and might not even work at all. Mario took on the task of figuring out how to coax LDAP into doing what we need. James pointed out RFC 4525, which adds a modify-increment operation to LDAP, but it is not known whether this extension is widely implemented, or actually has the necessary semantics to implement something like a semaphore. -Dan From jlentini at netapp.com Tue Aug 12 07:39:49 2008 From: jlentini at netapp.com (James Lentini) Date: Tue, 12 Aug 2008 10:39:49 -0400 (EDT) Subject: [Federated-fs] new conference call time? Message-ID: Hello everyone, I've received a request to hold our weekly call at a different time. Since this week is already underway, I think it is too late to adjust this week's schedule. I propose we meet on Thursday at 2:00 PM EST this week and wait until next week to make any adjustments. The proposal I've received is to keep the call on Thursday and move it ahead a half hour: 1:30-2:30 PM EST/10:30-11:30 AM PST. Would that work? Are there other times on Thursday or Wednesday that would work better? james -- James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com From jlentini at netapp.com Tue Aug 12 07:49:47 2008 From: jlentini at netapp.com (James Lentini) Date: Tue, 12 Aug 2008 10:49:47 -0400 (EDT) Subject: [Federated-fs] new conference call id Message-ID: Going forward, we will need to use a new conference call ID for our fedfs discussions. The new number is: 1-888-765-3653 # 2354843 From wurzl_mario at emc.com Tue Aug 12 11:20:48 2008 From: wurzl_mario at emc.com (wurzl_mario at emc.com) Date: Tue, 12 Aug 2008 14:20:48 -0400 Subject: [Federated-fs] new conference call time? In-Reply-To: References: Message-ID: <106895FCDEB50E4EB9828BB721BA590F161502@CORPUSMX80B.corp.emc.com> Thursday 1:30 - 2:30 EST would work for me. Mario -----Original Message----- From: federated-fs-bounces at sdsc.edu [mailto:federated-fs-bounces at sdsc.edu] On Behalf Of James Lentini Sent: Tuesday, August 12, 2008 10:40 To: federated-fs at sdsc.edu Subject: [Federated-fs] new conference call time? Hello everyone, I've received a request to hold our weekly call at a different time. Since this week is already underway, I think it is too late to adjust this week's schedule. I propose we meet on Thursday at 2:00 PM EST this week and wait until next week to make any adjustments. The proposal I've received is to keep the call on Thursday and move it ahead a half hour: 1:30-2:30 PM EST/10:30-11:30 AM PST. Would that work? Are there other times on Thursday or Wednesday that would work better? james -- James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com From LeMahieu_Paul at emc.com Tue Aug 12 11:34:02 2008 From: LeMahieu_Paul at emc.com (Paul Lemahieu) Date: Tue, 12 Aug 2008 11:34:02 -0700 Subject: [Federated-fs] new conference call time? In-Reply-To: References: Message-ID: <78CA2BDB-4B4B-4021-A991-719DE5D26D21@emc.com> That new time is fine with me. --Paul On 2008-Aug-12, at 7:39, James Lentini wrote: > > Hello everyone, > > I've received a request to hold our weekly call at a different time. > > Since this week is already underway, I think it is too late to adjust > this week's schedule. I propose we meet on Thursday at 2:00 PM EST > this week and wait until next week to make any adjustments. > > The proposal I've received is to keep the call on Thursday and move it > ahead a half hour: 1:30-2:30 PM EST/10:30-11:30 AM PST. > > Would that work? Are there other times on Thursday or Wednesday that > would work better? > > james > > -- > James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com > From androsadamson at gmail.com Tue Aug 12 11:24:37 2008 From: androsadamson at gmail.com (William A. (Andy) Adamson) Date: Tue, 12 Aug 2008 14:24:37 -0400 Subject: [Federated-fs] new conference call time? In-Reply-To: References: Message-ID: <89c397150808121124o58b4f69fn9996ef8976f5c89@mail.gmail.com> Thursday 1:30-2:30 EST will work for me. -->Andy On Tue, Aug 12, 2008 at 10:39 AM, James Lentini wrote: > > Hello everyone, > > I've received a request to hold our weekly call at a different time. > > Since this week is already underway, I think it is too late to adjust > this week's schedule. I propose we meet on Thursday at 2:00 PM EST > this week and wait until next week to make any adjustments. > > The proposal I've received is to keep the call on Thursday and move it > ahead a half hour: 1:30-2:30 PM EST/10:30-11:30 AM PST. > > Would that work? Are there other times on Thursday or Wednesday that > would work better? > > james > > -- > James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com > > From jlentini at netapp.com Wed Aug 13 13:28:12 2008 From: jlentini at netapp.com (James Lentini) Date: Wed, 13 Aug 2008 16:28:12 -0400 (EDT) Subject: [Federated-fs] new conference call time? In-Reply-To: References: Message-ID: On Tue, 12 Aug 2008, James Lentini wrote: > > Hello everyone, > > I've received a request to hold our weekly call at a different time. > > Since this week is already underway, I think it is too late to adjust > this week's schedule. I propose we meet on Thursday at 2:00 PM EST > this week and wait until next week to make any adjustments. > > The proposal I've received is to keep the call on Thursday and move it > ahead a half hour: 1:30-2:30 PM EST/10:30-11:30 AM PST. > > Would that work? Are there other times on Thursday or Wednesday that > would work better? > > james > > -- > James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com > To date, all the responses I've seen indicate that people will be able to make the call if we move it to 1:30-2:30 PM EST/10:30-11:30 AM PST Thursdays. Given the number of responses, I'm inclined to move tomorrows call to this time. Is there anyone who would be unable to make the call at this time tomorrow? From jlentini at netapp.com Thu Aug 14 06:43:53 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 14 Aug 2008 09:43:53 -0400 (EDT) Subject: [Federated-fs] reminder fed-fs conference call today Message-ID: This is a reminder that the fed-fs conference call today will be at a new time and use a new id: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Talk to you then, james -- James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com From jlentini at netapp.com Fri Aug 15 07:20:43 2008 From: jlentini at netapp.com (James Lentini) Date: Fri, 15 Aug 2008 10:20:43 -0400 (EDT) Subject: [Federated-fs] fed-fs meeting minutes, 8/14 Message-ID: Attendees --------- Renu Tewari (IBM/ARC) James Lentini (NetApp) Andy Adamson (NetApp) Theresa Lingutla-Raj (NetApp) Dan Ellard (BBN Technologies) Paul Lemahieu (EMC) Minutes ------- + NSDB Protocol Document Dan reviewed the changes he made to the NSDB protocol document. The document describes the write protocol(s) used to interact with the NSDB, but it does not cover an API for performing these operations. Dan asked if it would be helpful to include a C API in the document. Dan noted that the mechanism to answer questions an application is interested in, such as "What are all the FSLs for this FSN?", are not covered in the specification. The basic protocol operations operations are described, but there is not an example showing how to put these together to answer higher level question. The consensus was that high level examples should be added to the document. An example C API for accessing the NSDB could also be included, but would not be mandatory. Dan also noted that the LDAP attributes in section 8 were under specified. For example, an attribute that is supposed to be a network address (either a FQDN, IPv4 address, or IPv6 address) is only specified as a string type. This would allow garbage entries to be placed in the NSDB. There are two ways to approach this problem: (1) specify the types more exactly in LDAP or (2) wrap the LDAP database with a layer that checks for errors. James Lentini volunteered to investigate if (1) is possible. We then discussed the requirements for unique UUIDs. It was noted that a UUID can be generated by one or more administrative entities in the federation. There is currently no mechanism to guarantee that a new UUID being inserted into an NSDB is unique across the entire federation. The difficulty of guaranteeing uniqueness was discussed. First, checking the uniqueness of a UUID would require either synchronizing with all other NSDBs or having a central authority. There is also the issue of what happens when a FSN UUID is deleted when a junction still refers to it. If a new FSN with the same UUID is created, the junction would point to the new FSN which could be viewed as an error. It was pointed out that an FSN is defined as a (NSDB name, UUID) pair. This makes generating unique FSNs more tractable as the FSN's UUID only needs to differ from the other FSN UUIDs on the given NSDB. There is also a probabilistic argument that can be made for the uniqueness of the UUID. Dan suggested that we add text along these lines: "UUIDs must be unique in order for correct system operation. We can approximate correct operation using UUIDs generated using RFC4122. We also discussed the benefits and disadvantages of wrapping the LDAP service, option (2) above, further. Such a service could check for input errors, and generate/validate UUIDs, and return the FedFS errors in section 7, rather than LDAP errors (currently, there is no way to return the errors in section 7). What protocol would be used to communicate with this service? Web services protocols such as SOAP were discussed. ONC RPC was also suggested as an obvious candidate because NFS and the FedFS admin protocol already use it. It was noted that the protocol chosen would need to be implemented on the file server, so choosing something reasonable for that environment is important. Andy pointed out that if there was a wrapper around the database, then the protocol could be described, and the database backend could be changed. Finally, Dan noted that the LDAP schema that had been present in previous version of the document had been removed. The schema is in an OpenLDAP configuration file. The file is in the open source implementation that NetApp is open sourcing. Dan released NetApp's open source NSDB code last week. The code is available on ftp.netapp.com, user anonymous, password is your email address, at frm-ntap/opensource/snsdb-080806.tar. The proposal is to keep the specific LDAP schema configuration file out of the document. The document will have the intention, but not the specific implementation. + Next Meeting Next week we will cover the topics that we didn't get to this week: - Push vs Pull for master root fileset replicas - LDAP transactions - How do other protocols, such as CIFS and DFS, make use of FedFS? - Feedback on Dan's changes to NSDB Protocol document From ellard at gmail.com Fri Aug 15 18:41:01 2008 From: ellard at gmail.com (Daniel Ellard) Date: Fri, 15 Aug 2008 21:41:01 -0400 Subject: [Federated-fs] fed-fs meeting minutes, 8/14 In-Reply-To: References: Message-ID: A few clarifications below. On Fri, Aug 15, 2008 at 10:20 AM, James Lentini wrote: > > > Attendees > --------- > > Renu Tewari (IBM/ARC) > James Lentini (NetApp) > Andy Adamson (NetApp) > Theresa Lingutla-Raj (NetApp) > Dan Ellard (BBN Technologies) > Paul Lemahieu (EMC) > > Minutes > ------- > > + NSDB Protocol Document > > Dan reviewed the changes he made to the NSDB protocol document. > > The document describes the write protocol(s) used to interact with the > NSDB, but it does not cover an API for performing these operations. Dan > asked if it would be helpful to include a C API in the document. > > Dan noted that the mechanism to answer questions an application is interested > in, such as "What are all the FSLs for this FSN?", are not covered in the > specification. The basic protocol operations operations are described, but > there is not an example showing how to put these together to answer higher > level question. Actually, this is one of the queries that are covered in the spec. But there are many others that might be interesting that are not. For example, something like "give me a list of all the FSNs" is a trivial LDAP query, but never spec'd explicitly. A more complicated, nested query, is something like "tell me all the FSN-to-FSL mappings, with all their annotations". This requires a nested query -- first, to find all the FSNs, and second to find all the FSLs for each of them. (there are other ways to do this, of course) > The consensus was that high level examples should be added to the document. > An example C API for accessing the NSDB could also be included, but would > not be mandatory. > > Dan also noted that the LDAP attributes in section 8 were under specified. For > example, an attribute that is supposed to be a network address (either a FQDN, > IPv4 address, or IPv6 address) is only specified as a string type. This > would allow garbage entries to be placed in the NSDB. > > There are two ways to approach this problem: (1) specify the types more > exactly in LDAP or (2) wrap the LDAP database with a layer that checks for > errors. The third option is to push all the error checking out to the NSDB clients. In this model, the client is responsible for verifying everything that comes from the NSDB to make sure that it isn't garbage. This is where we are now (except that the prototype doesn't do all that much checking...). > James Lentini volunteered to investigate if (1) is possible. > > We then discussed the requirements for unique UUIDs. It was noted that a > UUID can be generated by one or more administrative entities in the > federation. There is currently no mechanism to guarantee that a new UUID > being inserted into an NSDB is unique across the entire federation. > > The difficulty of guaranteeing uniqueness was discussed. First, checking > the uniqueness of a UUID would require either synchronizing with all other > NSDBs or having a central authority. There is also the issue of what happens > when a FSN UUID is deleted when a junction still refers to it. If a new FSN > with the same UUID is created, the junction would point to the new FSN which > could be viewed as an error. > > It was pointed out that an FSN is defined as a (NSDB name, UUID) pair. This > makes generating unique FSNs more tractable as the FSN's UUID only needs to > differ from the other FSN UUIDs on the given NSDB. > > There is also a probabilistic argument that can be made for the uniqueness of > the UUID. > > Dan suggested that we add text along these lines: "UUIDs must be unique in > order for correct system operation. We can approximate correct operation using > UUIDs generated using RFC4122. > > We also discussed the benefits and disadvantages of wrapping the LDAP service, > option (2) above, further. Such a service could check for input errors, and > generate/validate UUIDs, and return the FedFS errors in section 7, rather > than LDAP errors (currently, there is no way to return the errors in section > 7). > > What protocol would be used to communicate with this service? > > Web services protocols such as SOAP were discussed. ONC RPC was also > suggested as an obvious candidate because NFS and the FedFS admin protocol > already use it. It was noted that the protocol chosen would need to be > implemented on the file server, so choosing something reasonable for that > environment is important. > > Andy pointed out that if there was a wrapper around the database, then the > protocol could be described, and the database backend could be changed. > > Finally, Dan noted that the LDAP schema that had been present in previous > version of the document had been removed. The schema is in an OpenLDAP > configuration file. The file is in the open source implementation that > NetApp is open sourcing. > > Dan released NetApp's open source NSDB code last week. The code is available > on ftp.netapp.com, user anonymous, password is your email address, at > frm-ntap/opensource/snsdb-080806.tar. > > The proposal is to keep the specific LDAP schema configuration file out of > the document. The document will have the intention, but not the specific > implementation. > > + Next Meeting > > Next week we will cover the topics that we didn't get to this week: > - Push vs Pull for master root fileset replicas > - LDAP transactions > - How do other protocols, such as CIFS and DFS, make use of FedFS? > - Feedback on Dan's changes to NSDB Protocol document > -Dan From ellard at gmail.com Thu Aug 21 06:41:31 2008 From: ellard at gmail.com (Daniel Ellard) Date: Thu, 21 Aug 2008 09:41:31 -0400 Subject: [Federated-fs] proposed agenda change Message-ID: Due to unanticipated events, I need to take my daughter to her pediatrician this afternoon, and therefore may miss some or all of the conference call. If everything thinks it's still OK to discuss the draft I sent out two weeks ago, that's fine, as long as someone takes detailed notes I can use to revise it. Otherwise, let's postpone for a week (or two, if people are out next week). Personally, I'll be disappointed if we can't get this done today (the sooner the better) but I probably won't be able to be there to help. -Dan From jlentini at netapp.com Thu Aug 21 07:14:13 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 21 Aug 2008 10:14:13 -0400 (EDT) Subject: [Federated-fs] proposed agenda change In-Reply-To: References: Message-ID: On Thu, 21 Aug 2008, Daniel Ellard wrote: > Due to unanticipated events, I need to take my > daughter to her pediatrician this afternoon, and > therefore may miss some or all of the conference > call. If everything thinks it's still OK to discuss the > draft I sent out two weeks ago, that's fine, as long > as someone takes detailed notes I can use to > revise it. Otherwise, let's postpone for a week (or > two, if people are out next week). > > Personally, I'll be disappointed if we can't get > this done today (the sooner the better) but I > probably won't be able to be there to help. > > -Dan > Thanks for the heads up Dan. Here's what I had recorded during the last meeting for this weeks topics: - Push vs Pull for master root fileset replicas - LDAP transactions - How do other protocols, such as CIFS and DFS, make use of FedFS? - Feedback on Dan's changes to NSDB Protocol document If we discuss the draft, I'll try to take good notes. From jlentini at netapp.com Thu Aug 21 07:16:20 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 21 Aug 2008 10:16:20 -0400 (EDT) Subject: [Federated-fs] conference call today Message-ID: This is a reminder that today's fed-fs conference call today be at our new time and use our new id: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 Talk to you then, james -- James Lentini | NetApp | 781-768-5359 | jlentini at netapp.com From tewarir at us.ibm.com Thu Aug 21 12:22:53 2008 From: tewarir at us.ibm.com (Renu Tewari) Date: Thu, 21 Aug 2008 12:22:53 -0700 Subject: [Federated-fs] MS-DFS related doucments Message-ID: James, As we discussed in today's call here all the docs related to MS-DFS and referrals and ADs that should keep us busy reading for the week and beyond :) All documents related to MS-DFS http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx The MS DFS referral protocol http://msdn.microsoft.com/en-us/library/cc202172.aspx Active directory spec (unbearably long) http://msdn.microsoft.com/en-us/library/cc200343.aspx Active Directory Schema classes http://msdn.microsoft.com/en-us/library/cc199751.aspx regards Renu Renu Tewari, Ph.D. Research Staff Member Networked Filesystems IBM Almaden. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.sdsc.edu/pipermail/federated-fs/attachments/20080821/49dddc47/attachment.html From jlentini at netapp.com Thu Aug 21 16:53:27 2008 From: jlentini at netapp.com (James Lentini) Date: Thu, 21 Aug 2008 19:53:27 -0400 (EDT) Subject: [Federated-fs] FedFS Minutes, 8/21/2008 Message-ID: FedFS Minutes, 8/21/2008 ------------------------ Attendees --------- Renu Tewari (IBM/ARC) James Lentini (NetApp) Paul Lemahieu (EMC) Manoj Naik (IBM/ARC) Minutes ------- + Precisely specifying LDAP types During the meeting last week, Dan lamented that the drafts do not define the LDAP NSDB types more precisely. Stronger types would keep many invalid values out of the LDAP database (e.g. a field containing an IP address would at least be syntactically valid). James Lentini is researching if this is possible. Paul will ask Mario if he has any pointers on this subject. Do we need do the error checking on the LDAP? We observed that there will still be error checking necessary by the server/admin utility. Renu noted that RFC 2307: An Approach for Using LDAP as a Network Information Service could be a good example of how to define the types more precisely. + Push vs Pull for master root fileset replicas We decided in previous meetings that the file servers will pull the master root fileset. The open issue is how to efficiently determine what has changed (what are the deltas?). + How do other protocols, such as CIFS and DFS, make use of FedFS? We came up with several questions: Should the NSDB return different answers for an NFS exported fs versus and CIFS exported fs? Can Active Directory be used as an NSDB? And if so, how? For a Windows environment, we should be careful about requiring Active Directory usage. Typically, the Active Directory administrators and the storage administrators are different people. Along the same lines, we don't want to require Active Directory. We will research the mechanism CIFS uses to implement referrals and what information MS DFS stores in active directory (the MS DFS documentation has information on this). + Agenda items for next week: - LDAP transactions - Feedback on Dan's changes to NSDB Protocol document From jlentini at netapp.com Wed Aug 27 16:02:01 2008 From: jlentini at netapp.com (James Lentini) Date: Wed, 27 Aug 2008 19:02:01 -0400 (EDT) Subject: [Federated-fs] FedFs meeting agenda for 8/28 Message-ID: We'll be meeting tomorrow at the new time and place: Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST Dial-in: 1-888-765-3653 # 2354843 >From last week, I had 2 topics for this weeks agenda: - Feedback on Dan's changes to the NSDB Protocol document (I'll take detailed minutes if Dan is unable to join) - LDAP transactions Please let me know if you would like to cover additional topics. From jlentini at netapp.com Fri Aug 29 07:25:43 2008 From: jlentini at netapp.com (James Lentini) Date: Fri, 29 Aug 2008 10:25:43 -0400 (EDT) Subject: [Federated-fs] FedFS Minutes, 8/28/2008 Message-ID: FedFS Minutes, 8/28/2008 ------------------------ Attendees --------- Dan Ellard (BBN) Renu Tewari (IBM/ARC) Robert Thurlow (Sun) Paul Lemahieu (EMC) James Lentini (NetApp) Manoj Naik (IBM/ARC) Theresa Lingutla-Raj (NetApp) Amy Weaver (NetApp) Minutes ------- + Feedback on Dan's changes to the NSDB Protocol document - Definition of a Junction The term junction is used to mean different things in different places. In some instances, a junction is an object internal to a server while in other places it is an external object. The suggestion was to clarify this terminology. Dan explained that the junction key is used to name the relation between two filesets that are linked by a junction. For each junction in the name space, there will be a junction key. A junction key is an attribute of a junction object. There was an earlier meaning of the term junction key in the specification. Dan believed he has removed these uses. It appears that the text in section 6.2.2 on page 15 is using the older definition of a "junction key". This text should be updated. To clarify the terminology, the junction key in the LDAP schema could be changed to a junction UUID. - Clarification of the root fileset? The goal is to provide a federation wide namespace, not a global namespace. The conclusion was that section 3.7 needs to be expanded/revised. - How are NSDBs replicated? The idea is that NDSBs would be replicated, but entries in an NSDB would not be replicated to other NSDBs. This is the proposed approach because it matches the features of different LDAP implementations. Support for replication between two arbitrary LDAP implementations (e.g. OpenLDAP and Active Directory) is not available. Dan believes that there may be a paragraph describing this in the document. He will either add or augment the existing text. - Consistency checks of the objects definitions Some of the descriptions in section 3.3 and the LDAP definitions are not consistent. For example, the text describing the FSL definition is different from LDAP definition (there are different fields). - Description of LDAP protocol versus APIs There had been a C API descriptions. The agreement was to describe the LDAP protocol. This is the most useful. There are many programming language APIs. - LDAP versus other things? We can do the things we want in LDAP now. For the next set of things (features) we don't know if LDAP will do what we want. + IETF feedback from Dublin The NFSv4 working group presentation went very well. There were three areas the audience requested we address: - security: the was concern that the referral mechanism could be miss-used to direct a client to a rogue server. The consensus was the security of the overall system is not decreased by using FedFs. We need to state that when using the existing NFS security measures (GSS API, etc) and LDAP security measures, the use of FedFs does not decrease security. Dan noted that there are now two systems (NFS + LDAP) to configure correctly. Does FedFs expose existing security issues to a wider audience (the entire world?). - root fileset/namespace: the issue raised was that clients can mount the namespace at different locations and different places in the federation namespace. Is there anyway to close this with NFS? We agreed that there was not. NFS clients are allowed to mount at any point in their namespace. The proposal is to provide a best practices guide for how NSDB's are setup and where clients should mount the federation namespace. This could be part of the admin document. What about loops in the namespace? It is difficult (impossible?) to protect against this. Keeping this from happening this is not a goal. - LDAP help from IETF There was a general offer of help on LDAP issues from the IETF + LDAP transactions We ran out of time (again) to discuss this topic.