[nfsv4] [FedFS] Multiple FSL resolution

<stacey_chris@emc.com> Thu, 10 December 2009 02:37 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 4E4C13A682E for <nfsv4@core3.amsl.com>; Wed, 9 Dec 2009 18:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 ERogz8F69I2n for <nfsv4@core3.amsl.com>; Wed, 9 Dec 2009 18:37:10 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id ABD383A6829 for <nfsv4@ietf.org>; Wed, 9 Dec 2009 18:37:09 -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 nBA2avcp005092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Wed, 9 Dec 2009 21:36:57 -0500
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Wed, 9 Dec 2009 21:36:48 -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 nBA2amDw011102 for <nfsv4@ietf.org>; Wed, 9 Dec 2009 21:36:48 -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 21:36:48 -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_01CA7941.9F13F379"
Date: Wed, 09 Dec 2009 21:36:46 -0500
Message-ID: <0F3F903BA6B4A54984787888AF6EA5C404671F46@CORPUSMX40A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [FedFS] Multiple FSL resolution
thread-index: Acp5QZ44aSYDgTm9TqKTnpzgnSIM0A==
From: stacey_chris@emc.com
To: nfsv4@ietf.org
X-OriginalArrivalTime: 10 Dec 2009 02:36:48.0322 (UTC) FILETIME=[9F238220:01CA7941]
X-EMM-EM: Active
Subject: [nfsv4] [FedFS] Multiple FSL resolution
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 02:37:13 -0000

Either an easily answered question or a possible topic for discussion in
tomorrow's FedFS call.

 

The requirements spec
(http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-reqts-06.txt)
talks about associating multiple FSL's with an FSN where the file sets
referred to by the FSL's are replicas of one another.  Maintenance of
the replicas is outside the scope of FedFS.    

 

When a client traverses a junction that refers to an FSN which has
multiple FSL's associated with it the file server queries the relevant
NSDB for the FSLs associated with the FSN (section 3.2, step 4).    But
only one of the potentially multiple FSLs is returned to the client in
the form of a protocol specific referral (section 3.2, step 5).      

 

How does the server decide which of multiple FSLs to return to a client?

 

Thanks,

Chris

-- 
Chris Stacey - Senior Technologist, Celerra Unified Storage Engineering,
EMC Corporation (New Zealand).  Phone: +64 21 225 3747