headers
Spencer Shepler | 4 Nov 2008 08:12

Send agenda items for Nov 21st NFSv4 WG meeting


The final agenda has been set for IETF 73. You will find it here:
https://datatracker.ietf.org/meeting/73/agenda.html

The NFSv4 WG meeting is scheduled for Friday the 21st at 9am.

Please send me proposed agenda items for this meeting such
that I can register them prior to the meeting.

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
James Lentini | 6 Nov 2008 15:27
Picon

FedFS meeting today (11/6)


We'll be meeting at the usual time and place:

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 # 2354843

Proposoed Agenda:
-----------------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each weeks meeting with this announcement.

+ Review action items

  [AI] James Lentini will created a revised draft of the requirements 
       an administrative tool will need to access junctions.

+ Root Fileset
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Lentini | 6 Nov 2008 15:51
Picon

[FedFS] second draft of R8 requirement


Below is the second draft, based on the feedback from last week, of 
the revised R8 requirement from draft-ietf-nfsv4-federated-fs-reqts-00:

The original version:
---------------------

   R8:   USING THE FEDERATION INTERFACES, it MUST be possible to perform
         queries about the state of objects relevant to the
         implementation of the federation namespace.

         It MUST be possible to query the fileserver named in an FSL to
         discover whether a junction exists at a given path within that
         FSL.

The modified version:
---------------------

   R8:   USING THE FEDERATION INTERFACES:

         a. It MUST be possible to query the fileserver named in an FSL to
            discover whether a junction exists at a given path within that
            FSL.

         b. It MAY be possible to query the fileserver named in an FSL
            to discover the junctions, if any, in that FSL. If this 
            feature is implemented, the fileserver SHOULD report each 
            junction's path within the FSL and the targeted FSN.
_______________________________________________
nfsv4 mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Renu Tewari | 6 Nov 2008 19:25
Picon

Fed-fs: Root fileset discussion continued

Two topics for discussion on the root fileset.

1. Revisit the single master root NSDB and other slave root NSDBs in light
of  LDAP replication.

I verified that OpenLDAP supports master-slave replication. Mario raised an
important concern that Active Directory and iPlanet do not support
mater-slave replication instead every LDAP server is a master and the last
update wins.
Here are some documents on OpenLDAP replication (syncrepl) that describes
the master-slave and multi-master modes.
http://www.openldap.org/doc/admin24/replication.html
http://www.openldap.org/doc/admin22/syncrepl.html

2. Define the root fileset schema.
There are two options here:

a.  Each (virtual) directory node is represented as  a record in LDAP
For example,
<fsnUUID=ROOT_FSN
 dirName= b,
 parent = fed-fs,
 last_update_time = update_seq#,
 type= junction,
 Target_FSN= fsn_uuid1>
This approach requires the NFSv4 server query each level of the root
fileset hierarchy on a client request.

b. The root fileset is represented as a record of all the paths from the
root to each leaf
(Continue reading)

Permalink | Reply | 501 comments |
headers
Robert Thurlow | 6 Nov 2008 19:39
Picon

Re: Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)

James Lentini wrote:

> I assume that the requirement will conclude with this paragraph from 
> the original document:
> 
>          Not all filesets in the federation are required to have a FSN
>          or be reachable by a FSL.  Only those filesets that are the
>          target of a junction (as described in R3) are required to have
>          an FSN.

I didn't find that I agreed with that, actually.  If files aren't
reachable via an FSN, they're not in the federation and won't
be seen by all clients - is that incorrect?  How?

Here's the wording I came up with, without "junction keys":

3.  Overview

    Today, there are collections of fileservers that inter-operate to
    provide a single namespace comprised of filesystem resources provided
    by different members of the collections, joined together with inter-
    filesystem references.  The namespace can either be assembled at the
    fileservers, the clients, or by an external namespace service, and
    is often not easy or uniform to manage.  The requirements in this
    draft are meant to lead to a uniform server-based namespace which
    is capable of spanning a whole enterprise and which is easy to
    manage.

    We define some terms to better describe the solution space.  A
    "fileset" is the abstract view of a filesystem in a uniform
(Continue reading)

Permalink | Reply | 16 comments |
headers
Everhart, Craig | 6 Nov 2008 20:45
Picon

Re: Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)

Robert, I generally like this cleanup very much.  Thanks.

I have to assume that the text that James pointed out was meant to mean
files and filesets that were supposed to be "root filesets",
discoverable through other (bootstrapping-like) means.

But I'm not sure what requirement R1.b. is meant to say.  Can you
illustrate it somehow?  It seems to me that an FSN isn't enough for
locating such an instance unless you can rely on an NSDB.  Is this
making some statement of availability of an NSDB service?

Thanks.

		Craig

> -----Original Message-----
> From: Robert Thurlow [mailto:robert.thurlow <at> sun.com] 
> Sent: Thursday, November 06, 2008 1:40 PM
> To: Lentini, James
> Cc: nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] Overview and R1 rewrites (was Re: FedFS 
> Meeting Minutes, 10/16/2008)
> 
> James Lentini wrote:
> 
> > I assume that the requirement will conclude with this 
> paragraph from 
> > the original document:
> > 
> >          Not all filesets in the federation are required to
(Continue reading)

Permalink | Reply | 13 comments |
headers
Robert Thurlow | 6 Nov 2008 21:18
Picon

Re: Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)

Everhart, Craig wrote:

> But I'm not sure what requirement R1.b. is meant to say.  Can you
> illustrate it somehow?  It seems to me that an FSN isn't enough for
> locating such an instance unless you can rely on an NSDB.  Is this
> making some statement of availability of an NSDB service?

>>     R1:   Requirements of each FSN:
>>
>>           a.  Each FSN MUST be globally unique by being composed of
>>               a reference to an NSDB and an identifier unique within
>>               that NSDB.
>>
>>           b.  The FSN MUST be sufficiently descriptive to locate an
>>               instance of the fileset it names within the 
>> federation at
>>               any time.

Hmmm, looking at this again, I don't see why we should have
R1.b. - if the FSN is globally unique, it can be used (via
the NSDB) to find an instance.  I had no visions of being
able to be without access to an NSDB (or locally cached
info from one).  How would you feel about drooping R1.b.?

Rob T
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 7 comments |
headers
James Lentini | 6 Nov 2008 21:21
Picon

Re: Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)


On Thu, 6 Nov 2008, Everhart, Craig wrote:

> Robert, I generally like this cleanup very much.  Thanks.
> 
> I have to assume that the text that James pointed out was meant to mean
> files and filesets that were supposed to be "root filesets",
> discoverable through other (bootstrapping-like) means.

That would be one example. The other example that I assume the 
original authors had in mind was of file server that is part of the 
federation and serving a (legacy) fileset that is not part of the 
namespace.

> But I'm not sure what requirement R1.b. is meant to say.  Can you
> illustrate it somehow?  It seems to me that an FSN isn't enough for
> locating such an instance unless you can rely on an NSDB.  Is this
> making some statement of availability of an NSDB service?
> 
> Thanks.
> 
> 		Craig
> 
> > -----Original Message-----
> > From: Robert Thurlow [mailto:robert.thurlow <at> sun.com] 
> > Sent: Thursday, November 06, 2008 1:40 PM
> > To: Lentini, James
> > Cc: nfsv4 <at> ietf.org
> > Subject: Re: [nfsv4] Overview and R1 rewrites (was Re: FedFS 
> > Meeting Minutes, 10/16/2008)
(Continue reading)

Permalink | Reply | 4 comments |
headers
James Lentini | 6 Nov 2008 21:24
Picon

Re: Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)


On Thu, 6 Nov 2008, Robert Thurlow wrote:

> Everhart, Craig wrote:
> 
> > But I'm not sure what requirement R1.b. is meant to say.  Can you
> > illustrate it somehow?  It seems to me that an FSN isn't enough for
> > locating such an instance unless you can rely on an NSDB.  Is this
> > making some statement of availability of an NSDB service?
> 
> > >     R1:   Requirements of each FSN:
> > > 
> > >           a.  Each FSN MUST be globally unique by being composed of
> > >               a reference to an NSDB and an identifier unique within
> > >               that NSDB.
> > > 
> > >           b.  The FSN MUST be sufficiently descriptive to locate an
> > >               instance of the fileset it names within the federation at
> > >               any time.
> 
> Hmmm, looking at this again, I don't see why we should have
> R1.b. - if the FSN is globally unique, it can be used (via
> the NSDB) to find an instance.  I had no visions of being
> able to be without access to an NSDB (or locally cached
> info from one).  How would you feel about drooping R1.b.?

I agree. It should not imply that the FSN can be used to locate a 
fileset without the NSDB.
_______________________________________________
nfsv4 mailing list
(Continue reading)

Permalink | Reply | 6 comments |
headers
Everhart, Craig | 6 Nov 2008 21:32
Picon

Re: Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)


> From: Lentini, James 
> On Thu, 6 Nov 2008, Everhart, Craig wrote:
> 
> > Robert, I generally like this cleanup very much.  Thanks.
> > 
> > I have to assume that the text that James pointed out was meant to 
> > mean files and filesets that were supposed to be "root filesets", 
> > discoverable through other (bootstrapping-like) means.
> 
> That would be one example. The other example that I assume 
> the original authors had in mind was of file server that is 
> part of the federation and serving a (legacy) fileset that is 
> not part of the namespace.

It's hard to think of this as a fileset "in the federation."

But now I remember what the original point was.  The original text,
re-line-wrapped:

  Not all filesets in the federation are required to have a
  FSN or be reachable by a FSL.  Only those filesets that are
  the target of a junction (as described in R3) are required
  to have an FSN.

The idea was that a single file server might export lots of filesets,
joined by intra-fileserver links through some internal mechanism.  That
is, a client would traverse from fileset A to fileset B, both on the
same server.  When the file server encountered the intra-fileserver link
at the leaf of fileset A that would take it to fileset B, it would
(Continue reading)

Permalink | Reply | 3 comments |

Gmane