[Federated-fs] updated NSDB draft
James Lentini
jlentini at netapp.com
Tue Sep 23 15:21:55 PDT 2008
On Fri, 19 Sep 2008, Everhart, Craig wrote:
> Three comments are included. I hope I'm interpreting the "diff"
> correctly.
<snip>
> > -Internet-Draft NSDB Protocol for Federated Filesystems
> > August 2008
> > -
> > -
> > - status: fls_status as defined by the NFSv4.1 status attribute
> > -
> > - info: as defined in NFSv4.1 fs_locations_info attribute
> > + fs_locations_server's fls_currency field. A currency
> > value of 0
> > + represents the latest version. Currency values are
> > less than or
> > + equal to zero
>
> Did we lose some text above here?
>
> > +
> > + Annotations: a list of name/value pairs that can be
> > interpreted by a
> > + fileserver and used to generate a referral. The
> > semantics of the
> > + name/value pair is not defined by this protocol and is
> > intended to
> > + be used by higher-level protocols. This field MAY be used to
> > + store the NFSv4.1 fl_locations_server's fls_info values
>
> Ditto with lost text?
I am proposing to make the FSL description consistent with the LDAP
definition of an FSL in section 8 and the LDIF for creating an FSL in
section 9. To do that, I've removed the attrs field that is described
here to contain an XDR object. This attrs field was not included in
either the descriptions in section 8 or 9.
The old text was:
old text
-----------------------
Each FSL consists of:
host_fqdn: the name of the host fileserver storing the physical data
pathname: the exported pathname at that host fileserver
attrs: additional attributes for this FSL, as described in the
FSL_ATTR structure
struct FSL_ATTR {
protocol_t type;
int32_t currency;
annotation_t annotations<>;
fs_status_t status;
opaque_t info<>;
}
The attributes associated with each FSL are:
type: the protocol(s) supported by the fileserver hosting this FSL
currency: the time lag of this FSL represented as the number of time
units it lags the latest version as defined by the NFSv4.1
fs_locations_info attribute. A currency value of 0 represents the
latest version. Currency values are less than or equal to zero
annotations: a list of name/value pairs that can be interpreted by
an individual NSDB. The semantics of the name/value pair is not
defined by this protocol and is intended to be used by higher-
level administration protocols
status: fls_status as defined by the NFSv4.1 status attribute
info: as defined in NFSv4.1 fs_locations_info attribute
----
On problem with the contents of the attrs field described above is
that the NFSv4.1 spec (as of rev 26) does not define an fls_status.
The new text I'm proposing is:
---
Each FSL consists of:
FslHost: the fully qualified domain name of the host fileserver
storing the physical data
FslPathname: the exported pathname at that host fileserver
FslUuid: the 128-bit UUID of the FSL
Type: the protocol that should be used to access this FSL (e.g.
NFSv4)
Currency: the time lag of this FSL represented as the number of time
units it lags the latest version as defined by the NFSv4.1
fs_locations_server's fls_currency field. A currency value of 0
represents the latest version. Currency values are less than or
equal to zero
Annotations: a list of name/value pairs that can be interpreted by a
fileserver and used to generate a referral. The semantics of the
name/value pair is not defined by this protocol and is intended to
be used by higher-level protocols. This field MAY be used to
store the NFSv4.1 fl_locations_server's fls_info values
---
The alternative would be to change the LDAP/LDIF to include the
fls_info field.
> >
> > 3.3.1. Mutual Consistency across Fileset Locations
> >
> > @@ -467,6 +441,14 @@ Internet-Draft NSDB Protocol for Feder
> > write location. The federation protocols, however, cannot prevent
> > subsequent changes to a read-only location nor guarantee point-in-
> > time consistency of a read-only location if the
> > read-write location
> > +
> > +
> > +
> > +Ellard, et al. Expires March 23, 2009
> > [Page 8]
> > + >
> > +Internet-Draft NSDB Protocol for Federated Filesystems
> > September 2008
> > +
> > +
> > is changing.
> >
> > Regardless of the type, all locations exist at the same
> > mount point
> > @@ -485,7 +467,7 @@ Internet-Draft NSDB Protocol for Feder
> > raises a concern for NFSv3 fileservers, which the
> > federation protocol
> > may support, that may lack such control.
> >
> > -3.4. Namespace Repository (NSDB)
> > +3.4. Namespace Database (NSDB)
> >
> > The NSDB service is a federation-wide service that provides
> > interfaces to define, update, and query FSN information and FSN to
> > @@ -498,13 +480,6 @@ Internet-Draft NSDB Protocol for Feder
> > analogous to that between the DNS service and a particular DNS
> > server.
> >
> > -
> > -
> > -Ellard, et al. Expires February 6, 2009
> > [Page 9]
> > - >
> > -Internet-Draft NSDB Protocol for Federated Filesystems
> > August 2008
> > -
> > -
> > The term local NSDB is shorthand for an NSDB location
> > that is known a
> > priori to a server. It is typically located within the same
> > federation member as the server, but this is not
> > required. A local
> > @@ -519,13 +494,26 @@ Internet-Draft NSDB Protocol for Feder
> > location to resolve a junction. Each NSDB location
> > supports an LDAP
> > interface and can be accessed by an LDAP client.
> >
> > + An NSDB may be replicated throught the federation. The
> > mechanism by
> > + which this is acheived is outside the scope of this
> > document. Many
> > + LDAP implementations support replication. These features MAY be
> > + used
> > +
> > +
> > +
> > +Ellard, et al. Expires March 23, 2009
> > [Page 9]
> > + >
> > +Internet-Draft NSDB Protocol for Federated Filesystems
> > September 2008
> > +
> > +
> > + to replicate the NSDB.
> > +
> > 3.5. Mount Points, Junctions and Referrals
> >
> > A mount point is a directory in a parent fileset where a target
> > fileset may be attached. If a client traverses the path
> > leading from
> > - the root of the namespace to the mount point of a fileset
> > it should
> > - be able to access the data in that fileset (assuming appropriate
> > - permissions).
> > + the root of the namespace to the mount point of a target
> > fileset it
> > + should be able to access the data in that target fileset (assuming
> > + appropriate permissions).
> >
> > The directory where a fileset is mounted is represented
> > by a junction
> > in the underlying filesystem. In other words, a junction can be
> > @@ -538,9 +526,10 @@ Internet-Draft NSDB Protocol for Feder
> > What data is used by the underlying file system to represent the
> > junction is not defined by this protocol. The essential
> > property is
> > that the server must be able to find, given the junction,
> > the FSN for
> > - the target fileset. The FSN (as described earlier)
> > contains both the
> > - NSDB location of the authoritative NSDB location and the
> > FsnUuid (a
> > - UUID for the fileset).
> > + the target fileset. The mechanism by which the server maps a
> > + junction to an FSN is outside the scope of this document. The FSN
> > + (as described earlier) contains both the NSDB location of the
> > + authoritative NSDB location and the FsnUuid (a UUID for
> > the fileset).
> >
> > When a client traversal reaches a junction, the client is
> > referred to
> > a list of FSLs associated with the FSN that was the target of the
> > @@ -553,14 +542,6 @@ Internet-Draft NSDB Protocol for Feder
> > fileset is mounted in the namespace. Filesets can be nested -- a
> > fileset can be mounted under another fileset.
> >
> > -
> > -
> > -
> > -Ellard, et al. Expires February 6, 2009
> > [Page 10]
> > - >
> > -Internet-Draft NSDB Protocol for Federated Filesystems
> > August 2008
> > -
> > -
> > 3.6. Federation Root FileServers
> >
> > A set of designated fileservers that render the common federation-
> > @@ -572,6 +553,14 @@ Internet-Draft NSDB Protocol for Feder
> > fileservers. If a client mounts from a non-root
> > fileserver then it
> > can traverse the part of the namespace that is visible
> > starting from
> > that fileserver. A client can mount multiple individual filesets
> > +
> > +
> > +
> > +Ellard, et al. Expires March 23, 2009
> > [Page 10]
> > + >
> > +Internet-Draft NSDB Protocol for Federated Filesystems
> > September 2008
> > +
> > +
> > from multiple non-root fileservers and chose to navigate the
> > namespace in any manner. How the client discovers the root
> > fileserver(s), if one is defined, is not in the scope of the
>
> Hm--I don't recall the text here, but it may want to point to the DNS
> SRV draft.
This is a false positive. I'm not proposing any changes to this text.
It is showing up in the diff because my earlier changes moved the root
fileset text so that it spans a page. Hence diff thinks I am adding
the header and footer into this paragraph. The text mentions the DNS
SRV mechanism. Please let me know if you have suggestions on how
to improve it. Here is the text as it is in the currently published
draft:
---
3.6. Federation Root FileServers
A set of designated fileservers that render the common federation-
wide namespace are called the federation root fileservers. The
federation protocol does not mandate that federation root fileservers
be defined. When a client mounts the root of the namespace from a
root fileserver it can traverse the entire federation-wide namespace.
It is not required for a client to mount from one of the root
fileservers. If a client mounts from a non-root fileserver then it
can traverse the part of the namespace that is visible starting from
that fileserver. A client can mount multiple individual filesets
from multiple non-root fileservers and chose to navigate the
namespace in any manner. How the client discovers the root
fileserver(s), if one is defined, is not in the scope of the
federation protocol. Numerous external techniques such as DNS SRV
records can be used for this.
---
More information about the Federated-fs
mailing list