Re: [nfsv4] [FedFS] Root fileset questions
James Lentini <jlentini@netapp.com> Thu, 10 December 2009 16:23 UTC
Return-Path: <jlentini@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0816A3A6A9E for <nfsv4@core3.amsl.com>; Thu, 10 Dec 2009 08:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.693
X-Spam-Level:
X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBEvV5PfpOt1 for <nfsv4@core3.amsl.com>; Thu, 10 Dec 2009 08:23:11 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 4D0063A6A13 for <nfsv4@ietf.org>; Thu, 10 Dec 2009 08:23:09 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.47,375,1257148800"; d="scan'208";a="286391406"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 10 Dec 2009 08:22:58 -0800
Received: from jlentini-linux.hq.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nBAGMvFo003108; Thu, 10 Dec 2009 08:22:57 -0800 (PST)
Date: Thu, 10 Dec 2009 11:22:57 -0500
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: stacey_chris@emc.com
In-Reply-To: <0F3F903BA6B4A54984787888AF6EA5C404671F59@CORPUSMX40A.corp.emc.com>
Message-ID: <alpine.LFD.2.00.0912101004480.18058@jlentini-linux.nane.netapp.com>
References: <0F3F903BA6B4A54984787888AF6EA5C404671F59@CORPUSMX40A.corp.emc.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1628050704-937438031-1260458833=:18058"
Content-ID: <alpine.LFD.2.00.0912101030210.18058@jlentini-linux.nane.netapp.com>
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] [FedFS] Root fileset questions
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2009 16:23:13 -0000
On Wed, 9 Dec 2009, stacey_chris@emc.com wrote: > > Another possible topic for discussion in tomorrow’s FedFS call. Yes, we can discuss this on the call today as well. We intentionally separated the standardization of a root fileset for the rest of the FedFS protocols. I sent an email to the WG mailing list last April describing this plan: http://www.ietf.org/mail-archive/web/nfsv4/current/msg06981.html The focus and interest has been on the core FedFS protocols. We've informally discussed a root fileset definition, but an official IETF proposal has not been made yet. > We have been talking about using DNS SRV records to locate file servers that > export the root fileset for a namespace. But how does a file server > wanting to export the root of a namespace know what that root fileset > contains? A root fileserver may export a normal filesystem (perhaps replicated between multiple fileservers) or a root fileserver may export a root fileset. In the former case, a root fileset is not necessary. > R15(b) of the requirements spec > (http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-reqts-06.txt) says > that the contents of the root fileset are defined/stored in the NSDB. That may be an implication of this requirement. The exact text is: b. It SHOULD be possible for a fileserver to locate an NSDB that stores the layout of a root fileset. Since the structure of the root fileset has not been defined, there is still some flexibility on what the NSDB stores. > R15(b) also says that it should be possible for the a fileserver to locate > an NSDB that stores the layout of a root fileset. > > I can’t remember where it is specified but the root fileset can contain only > directories and junctions. This was the consensus in our discussions on the topic. As I mentioned, a formal specification of the root fileset has not been proposed yet. > R15(g) says that each file server wishing to provide access to the root of a > namespace must render a representation of the root fileset for the namespace > by extracting the definition from the NSDB for that namespace. It is a SHOULD, not a MUST, and then only "If a root fileset is defined". > I have a few questions related to the above… > > > > (1) How does the file server know which NSDB to query to find out the > contents of the root fileset for a given namespace? Doesn’t it need a > special ‘root junction’ that identifies the authoritative NSDB for the root > fileset for the namespace? > Again, there isn't a definitive root fileset specification, so it could be defined to work in many different ways. A special 'root junction' would be one possibility. Another option would be to use the standard FedFS junction and FSN format, but define a special root FSL. Recall that there is already an FSL LDAP object hierarchy with a fedfsFsl superclass and a fedfsNfsFsl subclass. A 'fedfsRootFsl' could be defined for the root fileset. I'm sure that there are other options as well. > > (2) Given that a root fileset can contain junctions and directories and it > is stored in the NSDB, do we not need LDAP objectclass definitions for > junctions and directories in the NSDB? Forgive me if I missed them, I > just expected to find them in section 4.2 of > http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-protocol-03bis.txt. > If the root was rendered from an NSDB-based image, then one or more LDAP objects would be necessary. Again, if the root is a standard filesystem, then no NSDB-based image is necessary. > > Following from #2, it would be helpful to include equivalent LDAP examples > for junctions and directories in the NSDB in section 5.1 of the protocol > specification. > I think examples would make sense in a specification describing the root fileset, not in the NSDB specification. > > (3) R15(d) says that the root fileset definition must be able to be > replicated between NSDBs. This is a SHOULD, not a MUST. > That, and file server rendering the root > fileset to clients, leads to the question – how do replica NSDB's and/or > file servers that want to render the root fileset get updates? The > fedfs-rootfileset draft that Renu circulated back in Sep. '08 says that this > was discussed but no conclusion reached (thanks for digging that out for me > James). Seem like we need to come to a conclusion on this. > > I agree, this is an area that would need to be well defined in a root fileset specification. > (4) What is the authentication model for access to the contents of the root > file set? AUTH_NONE, AUTH_SYS? I think this is the question that came up > recently and started me looking into all this. > > > > (5) What is the security model within the root file set? Completely open? > Un-modifiable mode bits and ACLs that are open (read-only) to all? > > Security is another area that would need to be well defined in a root fileset specification. We've discussed this topic in the past, but I don't remember coming to any conclusions.
- [nfsv4] [FedFS] Root fileset questions stacey_chris
- Re: [nfsv4] [FedFS] Root fileset questions James Lentini
- Re: [nfsv4] [FedFS] Root fileset questions stacey_chris
- Re: [nfsv4] [FedFS] Root fileset questions Nicolas Williams