[nfsv4] [FedFS] Root fileset questions
<stacey_chris@emc.com> Thu, 10 December 2009 03:03 UTC
Return-Path: <stacey_chris@emc.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 0786D3A693C for <nfsv4@core3.amsl.com>; Wed, 9 Dec 2009 19:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.692
X-Spam-Level:
X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6saEVKzaQNL7 for <nfsv4@core3.amsl.com>; Wed, 9 Dec 2009 19:03:33 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id CF9223A69BF for <nfsv4@ietf.org>; Wed, 9 Dec 2009 19:03:32 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nBA33Lkx017622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Wed, 9 Dec 2009 22:03:21 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Wed, 9 Dec 2009 22:03:18 -0500
Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id nBA33HAY016765 for <nfsv4@ietf.org>; Wed, 9 Dec 2009 22:03:18 -0500
Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 22:03:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7945.526C296A"
Date: Wed, 09 Dec 2009 22:03:15 -0500
Message-ID: <0F3F903BA6B4A54984787888AF6EA5C404671F59@CORPUSMX40A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [FedFS] Root fileset questions
thread-index: Acp5RVFN+6tkAh66S7uBzVbM0/9PHw==
From: stacey_chris@emc.com
To: nfsv4@ietf.org
X-OriginalArrivalTime: 10 Dec 2009 03:03:17.0714 (UTC) FILETIME=[527D7B20:01CA7945]
X-EMM-EM: Active
Subject: [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 03:03:39 -0000
Another possible topic for discussion in tomorrow's FedFS call. 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? 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. 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. 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. 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? (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. 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. (3) R15(d) says that the root fileset definition must be able to be replicated between NSDBs. 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. (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? Thanks, Chris -- Chris Stacey - Senior Technologist, Celerra Unified Storage Engineering, EMC Corporation (New Zealand). Phone: +64 21 225 3747
- [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