RFC 7532
Namespace Database (NSDB) Protocol for Federated File Systems
Pages: 65
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 16 to 41
3. Examples
In this section we provide examples and discussion of the basic operations facilitated by the federated file system protocol: creating a fileset, adding a replica of a fileset, resolving a junction, and creating a junction.3.1. Creating a Fileset and Its FSL(s)
A fileset is the abstraction of a set of files and the directory tree that contains them. The fileset abstraction is the fundamental unit of data management in the federation. This abstraction is implemented by an actual directory tree whose root location is specified by a fileset location (FSL). In this section, we describe the basic requirements for starting with a directory tree and creating a fileset that can be used in the federation protocols. Note that we do not assume that the process of creating a fileset requires any transformation of the files or the directory hierarchy. The only thing that is required by this process is assigning the fileset a fileset name (FSN) and expressing the location of the implementation of the fileset as an FSL. There are many possible variations to this procedure, depending on how the FSN that binds the FSL is created and whether other replicas of the fileset exist, are known to the federation, and need to be bound to the same FSN.
It is easiest to describe this in terms of how to create the initial implementation of the fileset and then describe how to add replicas.3.1.1. Creating a Fileset and an FSN
The following administrative steps create an FSN, which is used to track all replicas of a single physical dataset. 1. Choose the NSDB node that will keep track of the FSL(s) and related information for the fileset. 2. Create an FSN in the NSDB node. The FSN UUID is chosen by the administrator or generated automatically by administration software. The former case is used if the fileset is being restored, perhaps as part of disaster recovery, and the administrator wishes to specify the FSN UUID in order to permit existing junctions that reference that FSN to work again. At this point, the FSN exists, but its fileset locations are unspecified. 3. For the FSN created above, create an FSL in the NSDB node that describes the physical location of the fileset data.3.1.2. Adding a Replica of a Fileset
Adding a replica is straightforward: the NSDB node and the FSN are already known. The only remaining step is to add another FSL. Note that the federation protocols provide only the mechanisms to register and unregister replicas of a fileset. Fileserver-to- fileserver replication protocols are not defined.3.2. Junction Resolution
A fileset may contain references to other filesets. These references are represented by junctions. If a file-access client requests access to a fileset object that is a junction, the fileserver resolves the junction to discover one or more FSLs that implement the referenced fileset. There are many possible variations to this procedure, depending on how the junctions are represented by the fileserver and how the fileserver performs junction resolution.
Step 4 is the only step that interacts directly with the federation
protocols. The rest of the steps may use platform-specific
interfaces.
1. The fileserver determines that the object being accessed is a
junction.
2. The fileserver does a local lookup to find the FSN of the target
fileset.
3. Using the FSN, the fileserver finds the NSDB node responsible for
the target FSN.
4. The fileserver contacts that NSDB node and asks for the set of
FSLs that implement the target FSN. The NSDB node responds with
a (possibly empty) set of FSLs.
5. The fileserver converts one or more of the FSLs to the location
type used by the file-access client (e.g., an NFSv4 fs_locations
attribute as described in [RFC5661]).
6. The fileserver redirects (in whatever manner is appropriate for
the client) the client to the location(s).
3.3. Example Use Cases for Fileset Annotations
Fileset annotations can convey additional attributes of a fileset.
For example, fileset annotations can be used to define relationships
between filesets that can be used by an auxiliary replication
protocol. Consider the scenario where a fileset is created and
mounted at some point in the namespace. A snapshot of the read-write
FSL of that fileset is taken periodically at different frequencies
(say, a daily or weekly snapshot). The different snapshots are
mounted at different locations in the namespace.
The daily snapshots are considered as different filesets from the
weekly ones, but both are related to the source fileset. We can
define an annotation labeling the filesets as source and replica.
The replication protocol can use this information to copy data from
one or more FSLs of the source fileset to all the FSLs of the replica
fileset. The replica filesets are read-only while the source fileset
is read-write.
This follows the traditional Andrew File System (AFS) model of
mounting the read-only volume at a path in the namespace different
from that of the read-write volume [AFS].
The federation protocol does not control or manage the relationship among filesets. It merely enables annotating the filesets with user- defined relationships. Another potential use for annotations is recording references to an FSN. A single annotation containing the number of references could be defined, or multiple annotations, one per reference, could be used to store detailed information on the location of each reference. As with the replication annotation described above, the maintenance of reference information would not be controlled by the federation protocol. The information would most likely be non-authoritative because the ability to create a junction does not require the authority to update the FSN record. In any event, such annotations could be useful to administrators for determining if an FSN is referenced by a junction.4. NSDB Configuration and Schema
This section describes how an NSDB is constructed using an LDAP Version 3 [RFC4510] directory. Section 4.1 describes the basic properties of the LDAP configuration that MUST be used in order to ensure compatibility between different implementations. Section 4.2 defines the new LDAP attribute types and the new object types; it also specifies how the distinguished name (DN) of each object instance MUST be constructed.4.1. LDAP Configuration
An NSDB is constructed using an LDAP directory. This LDAP directory MAY have multiple naming contexts. The LDAP directory's entry specific to Digital Signature Algorithm (DSA) (its rootDSE) has a multi-valued namingContext attribute. Each value of the namingContext attribute is the DN of a naming context's root entry (see [RFC4512]). For each naming context that contains federation entries (e.g., FSNs and FSLs): 1. There MUST be an LDAP entry that is superior to all of the naming context's federation entries in the Directory Information Tree (DIT). This entry is termed the NSDB Container Entry (NCE). The NCE's children are FSNs. An FSN's children are FSLs. 2. The naming context's root entry MUST include "fedfsNsdbContainerInfo" (defined in Section 4.2.2.1) as one of its object classes. The fedfsNsdbContainerInfo's fedfsNceDN attribute is used to locate the naming context's NCE.
If a naming context does not contain federation entries, it will not
contain an NCE, and its root entry will not include a
"fedfsNsdbContainerInfo" as one of its object classes.
A fedfsNsdbContainerInfo's fedfsNceDN attribute contains the
distinguished name (DN) of the NSDB Container Entry residing under
this naming context. The fedfsNceDN attribute MUST NOT be empty.
For example, an LDAP directory might have the following entries:
-+ [root DSE]
| namingContext: o=fedfs
| namingContext: dc=example,dc=com
| namingContext: ou=system
|
|
+---- [o=fedfs]
| fedfsNceDN: o=fedfs
|
|
+---- [dc=example,dc=com]
| fedfsNceDN: ou=fedfs,ou=corp-it,dc=example,dc=com
|
|
+---- [ou=system]
In this case, the "o=fedfs" namingContext has an NSDB Container Entry
at "o=fedfs", the "dc=example,dc=com" namingContext has an NSDB
Container Entry at "ou=fedfs,ou=corp-it,dc=example,dc=com", and the
"ou=system" namingContext has no NSDB Container Entry.
The NSDB SHOULD be configured with one or more privileged LDAP users.
These users are able to modify the contents of the LDAP database. An
administrator that performs the operations described in Section 5.1
SHOULD authenticate using the DN of a privileged LDAP user.
It MUST be possible for an unprivileged (unauthenticated) user to
perform LDAP queries that access the NSDB data. A fileserver
performs the operations described in Section 5.2 as an unprivileged
user.
All implementations SHOULD use the same schema. At minimum, each
MUST use a schema that includes all objects named in the following
sections, with all associated attributes. If it is necessary for an
implementation to extend the schema defined here, consider using one of the following ways to extend the schema: o Define a fedfsAnnotation key and values (see Section 4.2.1.6). Register the new key and values with IANA (see Section 7.1). o Define additional attribute types and object classes, then have entries inherit from a class defined in this document and from the implementation-defined ones. Given the above configuration guidelines, an NSDB SHOULD be constructed using a dedicated LDAP server. If LDAP directories are needed for other purposes, such as to store user account information, use of a separate LDAP server for those is RECOMMENDED. By using an LDAP server dedicated to storing NSDB records, there is no need to disturb the configuration of any other LDAP directories that store information unrelated to an NSDB.4.2. LDAP Schema
The schema definitions provided in this document use the LDAP schema syntax defined in [RFC4512]. The definitions are formatted to allow the reader to easily extract them from the document. The reader can use the following shell script to extract the definitions: <CODE BEGINS> #!/bin/sh grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??' <CODE ENDS> If the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do: <CODE BEGINS> sh extract.sh < spec.txt > fedfs.schema <CODE ENDS> The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".
Code components extracted from this document must include the
following license:
<CODE BEGINS>
/// #
/// # Copyright (c) 2015 IETF Trust and the persons identified
/// # as authors of the code. All rights reserved.
/// #
/// # The authors of the code are:
/// # J. Lentini, C. Everhart, D. Ellard, R. Tewari, and M. Naik.
/// #
/// # Redistribution and use in source and binary forms, with
/// # or without modification, are permitted provided that the
/// # following conditions are met:
/// #
/// # - Redistributions of source code must retain the above
/// # copyright notice, this list of conditions and the
/// # following disclaimer.
/// #
/// # - Redistributions in binary form must reproduce the above
/// # copyright notice, this list of conditions and the
/// # following disclaimer in the documentation and/or other
/// # materials provided with the distribution.
/// #
/// # - Neither the name of Internet Society, IETF or IETF
/// # Trust, nor the names of specific contributors, may be
/// # used to endorse or promote products derived from this
/// # software without specific prior written permission.
/// #
/// # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// # AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// # WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// # FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// # EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// # LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// # EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// #
<CODE ENDS>
4.2.1. LDAP Attributes
The following definitions are used in this document: o The name attribute described in [RFC4519]. o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in [RFC4517]. o The integerMatch rule described in [RFC4517]. o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described in [RFC4517]. o The octetStringMatch rule described in [RFC4517]. o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in [RFC4517]. o The booleanMatch rule described in [RFC4517]. o The distinguishedNameMatch rule described in [RFC4517]. o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in [RFC4517]. o The labeledURI attribute described in [RFC2079]. o The UUID syntax (1.3.6.1.1.16.1) described in [RFC4530]. o The UuidMatch rule described in [RFC4530]. o The UuidOrderingMatch rule described in [RFC4530].
4.2.1.1. fedfsUuid
A fedfsUuid is the base type for all of the universally unique identifiers (UUIDs) used by the federated file system protocols. The fedfsUuid type is based on rules and syntax defined in [RFC4530]. A fedfsUuid is a single-valued LDAP attribute. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' /// DESC 'A UUID used by NSDB' /// EQUALITY uuidMatch /// ORDERING uuidOrderingMatch /// SYNTAX 1.3.6.1.1.16.1 /// SINGLE-VALUE /// ) /// <CODE ENDS>4.2.1.2. fedfsFsnUuid
A fedfsFsnUuid represents the UUID component of an FSN. An NSDB SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid. This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsFsnUuid' /// DESC 'The FSN UUID component of an FSN' /// SUP fedfsUuid /// SINGLE-VALUE /// ) /// <CODE ENDS>
4.2.1.3. fedfsFsnTTL
A fedfsFsnTTL is the time-to-live in seconds of a cached FSN and its child FSL records. It corresponds to the FsnTTL as defined in Section 2.7. See also Section 2.8.3 for information about caching FSLs. A fedfsFsnTTL MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 4294967295]. This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFsnTTL' /// DESC 'Time to live of an FSN tree' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.4. fedfsNceDN
A fedfsNceDN stores a distinguished name (DN). This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.14 NAME 'fedfsNceDN' /// DESC 'NCE Distinguished Name' /// EQUALITY distinguishedNameMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517].
4.2.1.5. fedfsFslUuid
A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure that no two FSLs it stores have the same fedfsFslUuid. This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid' /// DESC 'UUID of an FSL' /// SUP fedfsUuid /// SINGLE-VALUE /// ) /// <CODE ENDS>4.2.1.6. fedfsAnnotation
A fedfsAnnotation contains an object annotation formatted as a key/ value pair. This attribute is multi-valued; an object type that permits annotations may have any number of annotations per instance. A fedfsAnnotation attribute is a human-readable sequence of UTF-8 characters with no non-terminal NUL characters. The value MUST be formatted according to the following ABNF [RFC5234] rules: ANNOTATION = KEY "=" VALUE KEY = ITEM VALUE = ITEM ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP DQUOTE and WSP are defined in [RFC5234], and UTF8-octets is defined in [RFC3629]. The following escape sequences are allowed: +-----------------+-------------+ | escape sequence | replacement | +-----------------+-------------+ | \\ | \ | | \" | " | +-----------------+-------------+
A fedfsAnnotation value might be processed as follows:
1. Parse the attribute value according to the ANNOTATION rule,
ignoring the escape sequences above.
2. Scan through results of the previous step and replace the escape
sequences above.
A fedfsAnnotation attribute that does not adhere to this format
SHOULD be ignored in its entirety. It MUST NOT prevent further
processing of its containing entry.
The following are examples of valid fedfsAnnotation attributes:
"key1" = "foo"
"another key" = "x=3"
"key-2" = "A string with \" and \\ characters."
"key3"="bar"
These correspond to the following key/value pairs:
+-------------+-----------------------------------+
| key | value |
+-------------+-----------------------------------+
| key1 | foo |
| another key | x=3 |
| key-2 | A string with " and \ characters. |
| key3 | bar |
+-------------+-----------------------------------+
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation'
/// DESC 'Annotation of an object'
/// SUP name
/// )
///
<CODE ENDS>
4.2.1.7. fedfsDescr
A fedfsDescr stores an object description. The description MUST be encoded as a UTF-8 string. This attribute is multi-valued, which permits any number of descriptions per entry. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' /// DESC 'Description of an object' /// SUP name /// ) /// <CODE ENDS>4.2.1.8. fedfsNfsURI
A fedfsNfsURI stores the host and pathname components of an FSL. A fedfsNfsURI MUST be encoded as an NFS URI (see Section 2.8.1). The fedfsNfsURI is a subtype of the labeledURI type [RFC2079], with the same encoding rules. This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.120 NAME 'fedfsNfsURI' /// DESC 'Location of fileset' /// SUP labeledURI /// SINGLE-VALUE /// ) /// <CODE ENDS>
4.2.1.9. fedfsNfsCurrency
A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's fls_currency value [RFC5661]. A fedfsNfsCurrency MUST be encoded as an Integer syntax value [RFC4517] in the range [-2147483648, 2147483647]. This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency' /// DESC 'up-to-date measure of the data' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.10. fedfsNfsGenFlagWritable
A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1 FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit is set. A value of "FALSE" indicates the bit is not set. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable' /// DESC 'Indicates if the file system is writable' /// EQUALITY booleanMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.11. fedfsNfsGenFlagGoing
A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1 FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is set. A value of "FALSE" indicates the bit is not set. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing' /// DESC 'Indicates if the file system is going' /// EQUALITY booleanMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].4.2.1.12. fedfsNfsGenFlagSplit
A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1 FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is set. A value of "FALSE" indicates the bit is not set. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit' /// DESC 'Indicates if there are multiple file systems' /// EQUALITY booleanMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.13. fedfsNfsTransFlagRdma
A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1 FSLI4TF_RDMA bit [RFC5661]. A value of "TRUE" indicates the bit is set. A value of "FALSE" indicates the bit is not set. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma' /// DESC 'Indicates if the transport supports RDMA' /// EQUALITY booleanMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].4.2.1.14. fedfsNfsClassSimul
A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL [RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul' /// DESC 'The simultaneous-use class of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.15. fedfsNfsClassHandle
A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE [RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle' /// DESC 'The handle class of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.16. fedfsNfsClassFileid
A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID [RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid' /// DESC 'The fileid class of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.17. fedfsNfsClassWritever
A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER [RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever' /// DESC 'The write-verifier class of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.18. fedfsNfsClassChange
A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE [RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange' /// DESC 'The change class of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.19. fedfsNfsClassReaddir
A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR [RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir' /// DESC 'The readdir class of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.20. fedfsNfsReadRank
A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK [RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank' /// DESC 'The read rank of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.21. fedfsNfsReadOrder
A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER [RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder' /// DESC 'The read order of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.22. fedfsNfsWriteRank
A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661] value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank' /// DESC 'The write rank of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.23. fedfsNfsWriteOrder
A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661] value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax value [RFC4517] in the range [0, 255]. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder' /// DESC 'The write order of the file system' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].4.2.1.24. fedfsNfsVarSub
A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4IF_VAR_SUB bit [RFC5661]. A value of "TRUE" indicates the bit is set. A value of "FALSE" indicates the bit is not set. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub' /// DESC 'Indicates if variable substitution is present' /// EQUALITY booleanMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SINGLE-VALUE /// ) /// <CODE ENDS> OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.25. fedfsNfsValidFor
A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info fli_valid_for value [RFC5661]. A fedfsNfsValidFor MUST be encoded as an Integer syntax value [RFC4517] in the range [-2147483648, 2147483647]. An FSL's parent's fedfsFsnTTL value and its fedfsNfsValidFor value MAY be different. This attribute is single-valued. <CODE BEGINS> /// /// attributetype ( /// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor' /// DESC 'Valid for time' /// EQUALITY integerMatch /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SINGLE-VALUE /// ) /// OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. <CODE ENDS>
4.2.2. LDAP Object Classes
4.2.2.1. fedfsNsdbContainerInfo
A fedfsNsdbContainerInfo describes the location of the NCE. A fedfsNsdbContainerInfo's fedfsNceDN attribute is REQUIRED. A fedfsNsdbContainerInfo's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. <CODE BEGINS> /// /// objectclass ( /// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsNsdbContainerInfo' /// DESC 'Describes NCE location' /// SUP top AUXILIARY /// MUST ( /// fedfsNceDN /// ) /// MAY ( /// fedfsAnnotation /// $ fedfsDescr /// )) /// <CODE ENDS>
4.2.2.2. fedfsFsn
A fedfsFsn represents an FSN. A fedfsFsn's fedfsFsnUuid and fedfsFsnTTL attributes are REQUIRED. A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. The DN of an FSN is REQUIRED to take the following form: "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN and $NCE is the DN of the NCE. Since LDAP requires a DN to be unique, this ensures that each FSN entry has a unique UUID value within the LDAP directory. <CODE BEGINS> /// /// objectclass ( /// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsn' /// DESC 'Represents a fileset' /// SUP top STRUCTURAL /// MUST ( /// fedfsFsnUuid /// $ fedfsFsnTTL /// ) /// MAY ( /// fedfsAnnotation /// $ fedfsDescr /// )) /// <CODE ENDS>
4.2.2.3. fedfsFsl
The fedfsFsl object class represents an FSL. The fedfsFsl is an abstract object class. Protocol-specific subtypes of this object class are used to store FSL information. The fedfsNfsFsl object class defined in Section 4.2.2.4 is used to record an NFS FSL's location. Other subtypes MAY be defined for other protocols (e.g., Common Internet File System (CIFS)). A fedfsFsl's fedfsFslUuid and fedfsFsnUuid attributes are REQUIRED. A fedfsFsl's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. The DN of an FSL is REQUIRED to take the following form: "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE", where $FSLUUID is the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the NCE. Since LDAP requires a DN to be unique, this ensures that each FSL entry has a unique UUID value within the LDAP directory. <CODE BEGINS> /// /// objectclass ( /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl' /// DESC 'A physical location of a fileset' /// SUP top ABSTRACT /// MUST ( /// fedfsFslUuid /// $ fedfsFsnUuid /// ) /// MAY ( /// fedfsAnnotation /// $ fedfsDescr /// )) /// <CODE ENDS>
4.2.2.4. fedfsNfsFsl
A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl inherits all of the attributes of the fedfsFsl and extends the fedfsFsl with information specific to the NFS protocol. The DN of an NFS FSL is REQUIRED to take the following form: "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE", where $FSLUUID is the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the NCE. Since LDAP requires a DN to be unique, this ensures that each NFS FSL entry has a unique UUID value within the LDAP directory. <CODE BEGINS> /// /// objectclass ( /// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl' /// DESC 'An NFS location of a fileset' /// SUP fedfsFsl STRUCTURAL /// MUST ( /// fedfsNfsURI /// $ fedfsNfsCurrency /// $ fedfsNfsGenFlagWritable /// $ fedfsNfsGenFlagGoing /// $ fedfsNfsGenFlagSplit /// $ fedfsNfsTransFlagRdma /// $ fedfsNfsClassSimul /// $ fedfsNfsClassHandle /// $ fedfsNfsClassFileid /// $ fedfsNfsClassWritever /// $ fedfsNfsClassChange /// $ fedfsNfsClassReaddir /// $ fedfsNfsReadRank /// $ fedfsNfsReadOrder /// $ fedfsNfsWriteRank /// $ fedfsNfsWriteOrder /// $ fedfsNfsVarSub /// $ fedfsNfsValidFor /// )) /// <CODE ENDS>
(next page on part 3)