[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