One document matched: draft-dipankar-nfsv4-pathless-objects-01.txt
Differences from draft-dipankar-nfsv4-pathless-objects-00.txt
Internet Engineering Task Force Dipankar Roy
Internet-Draft Mike Eisler
Intended status: Standards Track Alex RN
Expires: April 7, 2011 NetApp
October 4, 2010
NFS Pathless Objects
draft-dipankar-nfsv4-pathless-objects-01.txt
Abstract
This document describes a set of NFS operations for creating,
maintaining and searching filesystem objects independent of the
traditional hierarchical namespace.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 7, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Dipankar Roy, et al. Expires April 7, 2011 [Page 1]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Pathless Objects and Object Sets . . . . . . . . . . . . . 4
3.2. Object Root Filehandle . . . . . . . . . . . . . . . . . . 5
3.3. Optional Features . . . . . . . . . . . . . . . . . . . . 6
3.4. Interaction with stateful NFS operations . . . . . . . . . 6
4. New file types . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Search Attributes . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Search Attributes Definition . . . . . . . . . . . . . . . 7
5.2. Search Attributes usage . . . . . . . . . . . . . . . . . 9
5.3. Search Attributes Query . . . . . . . . . . . . . . . . . 9
6. New Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Operation 1: PUTOBJROOTFH - Set Object Root Filehandle . . 12
6.2. Operation 2: PUTSRCHATTR: Search for an Object based
on Search Attributes . . . . . . . . . . . . . . . . . . . 12
7. Modifications to existing NFSv4.1 operations . . . . . . . . . 14
7.1. CREATE: Modifications . . . . . . . . . . . . . . . . . . 14
7.2. OPEN: Modifications . . . . . . . . . . . . . . . . . . . 14
7.3. LOOKUP: Modifications . . . . . . . . . . . . . . . . . . 14
7.4. READDIR: Modifications . . . . . . . . . . . . . . . . . . 15
8. Migration and Replication . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Dipankar Roy, et al. Expires April 7, 2011 [Page 2]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
1. Terminology
NFS: Used to refer to Network File System irrespective of the
version.
NFSv3: Network File System Version 3
NFSv4: Network File System Version 4
NFSv4.1: Network File System Version 4.1
ACL: Access Control List
HTTP: Hyper Text Transfer Protocol
REST: Representational State Transfer
2. Introduction
The NFS protocol is presently capable of interacting with objects
which can be represented by a pathname and a filehandle, residing in
a hierarchical namespace exported by the NFS server. However, such a
hierarchical namespace which tries to resemble the UNIX filesystem
layout and interface imposes restrictions on the filesystem object
locations and does not scale well in the case we need to store
billions of files inside a flat directory structure.
The rapidly developing distributed web applications of today, such as
those implementing the HTTP REST protocol, need to store billions of
objects, which do not need any directory hierarchy and instead must
have the capability to specify custom object attributes and quickly
search for the objects based on these attributes. To facilitate
this, an object needs to become independent of the filesystem
directory hierarchy that has been mandated by the NFS server until
now. In other words, the requirement is to have filesystem objects
which can be created, queried for and destroyed without being
associated with a pathname. These objects do not need to become
visible under a standard NFS exported hierarchical pathname but need
to be looked up based on tags or custom attributes. This RFC
presents the operations that are required by the NFS protocol to
implement such a feature of pathless filesystem objects.
Separation of the pathname from the filesystem object provides the
implementation greater flexibility on where to store the object,
which can lead to an optimal distribution of the filesytem objects
based on application requirements. Such an filesystem object is
looked up by the client based on the attributes of the object, rather
Dipankar Roy, et al. Expires April 7, 2011 [Page 3]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
than it's location in a directory, and is accessed by it's NFS
filehandle directly. This new object, though it does not have a
pathname, can still optionally have a name, which MAY be implemented
as an attribute for the object. The existing set of NFS attributes
needs to be extended to support a model where lookup of filesystem
objects can be done based on attributes.
With the introduction of NFSv4, the NFS protocol enforces
statefulness for interacting with filesystem objects. There are many
applications which require the stateful model of NFSv4. But there
are also many web oriented object stores, which can be simultaneously
accessed over other stateless protocols such as http, ftp etc. and
hence are not very interested in statefulness. Rather, they would
like to have the flexibility of using the stateless nature of NFSv3
along with some interesting features of NFSv4 such as ACLs, Named
Attributes, Compound Operations etc. which do not depend on the
statefulness of the NFS server for functionality. Stateless
operations provide the benefit of better performance as functional
and maintenance costs for the implementations are significantly less.
The object stores which will potentially handle billions of objects
and have no need for state maintenance can greatly benefit from the
improved performance of a stateless NFS implementation.
In light of the above, anonymous states are RECOMMENDED to be used
with this RFC, which means a stateid of all zeroes SHOULD be used for
NFSv4 and NFSv4.1 READ, WRITE and SETATTR operations on pathless
objects. At the same time, also keeping in mind the requirements of
applications which need to maintain locks at the server, advisory
locking SHOULD be supported. Delegations and shared locking support
is OPTIONAL with the implementation of this RFC.
3. Protocol Overview
3.1. Pathless Objects and Object Sets
To create an object independent of a pathname, the client sends a
request to the server to create the object without specifying any
name or pathname and the server returns the NFS filehandle for the
object thus created. A new object type called NF4NOPATHOBJ is
defined in this RFC, which SHOULD be used to create pathless objects.
Since pathless objects cannot be looked up based on pathname, a new
type of attribute, called Search Attribute is defined in this RFC,
which SHOULD be used to lookup the pathless objects. The NFSv4.1
READ and WRITE operations SHOULD be used to perform I/O on pathless
objects and attributes, including search attributes, can be set using
SETATTR and retrieved using GETATTR operations. A pathless object
SHOULD support the mandatory set of attributes defined in RFC 5661
Dipankar Roy, et al. Expires April 7, 2011 [Page 4]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
for a filesystem object.
Along with creating objects which are independent of pathnames, it is
REQUIRED to have a mechanism to classify together such objects, for
accessibility and scoped access resolution. This RFC uses the term
"Object Set" for representing such a collection of objects. An
Object Set works as a container for pathless objects and MUST be
defined and created before a pathless object is created. It is
analogous to a directory, where the object is analogous to a file
inside the directory. An Object Set contains objects and MAY
OPTIONALLY also contain other Object Sets.
When the client has created an Object Set or has access to an
existing Object Set within the server, it can create pathless objects
that are contained in the Object Set. The pathless object, even
though it is contained in a Set, can be physically located anywhere.
It is not necessary to implement a pathless object as a file. It can
be any physical entity, which has a unique identifier in the form of
a NFS filehandle. So the filehandle serves as an unique identifier
for the object and there is no requirement that it SHOULD represent a
file. The server is REQUIRED to maintain the linkage between the
object and it's Set and is free to distribute and store the objects
in the best possible way to satisfy the needs of the application.
An Object Set is expected to have certain access primitives
associated with it, which are used by the server to provide access
control for the objects contained in the Set. The server can
implement a policy based mechanism to grant specific clients or
groups of clients access to an Object Set. Such an implementation can
be analogous to the exports mechanism commonly used with the NFS
exported directories. The NFS server MUST keep track of all the
Object Sets it has. The server SHOULD make visible all the exported
Object Sets to the clients, subject to access control policies at the
server. This RFC does not pose any other requirements on the
implementation of an access policy for an Object Set.
An Object Set MUST have a name, which MAY be implemented as an
attribute of the Set. However, unlike the name of a pathless object,
the name of an Object Set MUST be unique for the NFS server. When
the client first creates an Object Set, it MUST specify a name for
the Object Set. The server returns a filehandle for the Object Set to
the client.
3.2. Object Root Filehandle
The NFS server supporting the Object Set and pathless object creation
MUST also have a well known public filehandle, hereby named as
"Object Root Filehandle", in short form objrootfh. This public
Dipankar Roy, et al. Expires April 7, 2011 [Page 5]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
filehandle is required for the purpose of informing the client that
the server implements support for this RFC.The client SHOULD send an
operation named PUTOBJROOTFH to set the current filehandle to
objrootfh. The server which implements this RFC, MUST set the
current filehandle to objrootfh and return NFS4_OK. This objrootfh
filehandle SHOULD be different from the public filehandle that an
NFSv4 server supports under the PUTROOTFH operation. The Object Root
Filehandle serves as a master container for all the Object Sets. The
client can send a query to the server to list all the Object Sets
that are available to it for access under the Object Root Filehandle.
Such a query can be specified as {PUTOBJROOTFH, READDIR}, where the
requested attributes specified in the READDIR request would indicate
if the server should reply with the Object Sets under the current
filehandle.
3.3. Optional Features
Since the pathless objects MAY not be implemented as files, and this
RFC RECOMMENDS stateless operation as much as possible, the following
features are explicitly being made OPTIONAL:
1. Supporting the POSIX semantics for interaction with pathless
objects.
2. Specifying a name to create a pathless object. Note that Object
Sets MUST have unique names.
3. Support for either Exclusive Create or Soft and Hard links.
4. Support for non-regular filesystem objects such as device files.
5. Support for delegations and share locks
If links are implemented, it SHOULD link to the object based on the
object name attribute, rather than a pathname. So it is a matter of
having multiple values for the attribute name, which is already a
feature for the search attributes.
3.4. Interaction with stateful NFS operations
The pathless objects are RECOMMENDED to be stateless. As such, the
anonymous stateid of zero SHOULD be used for operations like READ,
WRITE, SETATTR etc. However, if a server wants to implement stateful
NFSv4.1 operations with pathless objects, it can do so given that it
conforms to the specifications of NFSv4.1 RFC. So, existing NFSv4
READ, WRITE operations will work with pathless objects without any
changes to the operation definitions as stated in NFSv4.1 RFC. The
NFSv4.1 locking model is applicable to pathless objects, but only
Dipankar Roy, et al. Expires April 7, 2011 [Page 6]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
advisory locking MUST be supported. But if a server decides to
implement support for share locks and delegations, it MUST follow the
NFSv4.1 RFC locking semantics.
4. New file types
The pathless objects are not necessarily files or any other
filesystem object that can be defined with the existing nfs_fype4
type as specified in RFC 5661. The same holds for Object Sets. So
two new types are being introduced with this RFC, namely NF4NOPATH
and NF4OBJSET. So the definition of nfs_ftype4 is changed to include
the new file types and is as follows:
enum nfs_ftype4 {
NF4REG = 0x1;
NF4DIR = 0x2;
NF4BLK = 0x3;
NF4CHR = 0x4;
NF4LNK = 0x5;
NF4SOCK = 0x6;
NF4ATTRDIR = 0x7;
NF4NAMEDATTR = 0x8;
NF4NOPATHOBJ = 0x9;
NF4OBJSET = 0x10;
}
5. Search Attributes
5.1. Search Attributes Definition
In a hierarchical filesystem, the NFS client can do LOOKUP operations
based on pathname for a filesystem object but this will not work in
the case of pathless objects. So with pathless objects, the server
SHOULD support some kind of attributes which can be used to search
for such objects. These attributes are hereby called "Search
Attributes". These attributes have a name and a list of values. The
values can be of type integer or string. Search attributes can be
combined to form a query which looks up objects matching the
attributes specified in the query, as per the query semantics.
Two new attributes are added to the existing set of RECOMMENDED
attributes for NFSv4.1. One is a boolean attribute called
sattrsupport and the other is an array of strings called
srchattrlist. The sattrsupport denotes whether the server supports
search attributes. The srchattrlist contains the search attributes.
Dipankar Roy, et al. Expires April 7, 2011 [Page 7]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
The GETATTR and SETATTR operations can be used to retrieve and set
the search attributes. The sattrsupport applies to the filesystem
and the srchattrlist applies to an object in that filesystem.
The basic data types used in this RFC are same as the data types
defined in RFC 5661 Section 3.2. Some new structured data types are
added in this section to define the Search Attributes. One is a type
specifier for the Search Attribute value i. whether it is a number or
a string and is defined as "svaltype". The "sval" represents a
single value for a Search Attribute, of type svaltype. The "svalist"
is a set of such values for the Search Attribute. The Search
Attribute itself is defined as "srchattr" and contains a name of type
component4, the svaltype and svalist. A collection of Search
Attributes is defined as srchattrlist.
+----------------+----+--------------+-----+
| Name | Id | Data Type | Acc |
+----------------+----+--------------+-----+
| sattrsupport | 75 | bool | R |
| srchattrlist | 76 | srchattr<> | R W |
+------------------------------------------+
bool sattrsupport; /* indicates search attributes are supported */
enum svaltype {
SVAL_TYPE_NUM = 0; /* Search Attribute value is a number */
SVAL_TYPE_STR = 1; /* Search Attribute value is a string */
};
/* single search attribute value */
union sval switch (svaltype type) {
case SVAL_TYPE_NUM:
int64_t svalnum;
case SVAL_TYPE_STR:
component4 svalstr;
default:
void;
};
typedef struct sval svalist<>; /* array of attribute values */
struct srchattr {
component4 srchattrname; /* name of the search attribute */
svaltype type; /* type of the search attribute */
svalist srchvalist; /* list of values for this attr */
};
typedef struct srchattr srchattrlist<>;
Dipankar Roy, et al. Expires April 7, 2011 [Page 8]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
5.2. Search Attributes usage
Since there is no pathname, we cannot use the NFSv4 LOOKUP operation
to lookup a pathless object. Instead, the new search attributes are
used to look up a pathless object. These are represented as name
value pairs where the name is a string and the value is an array of
numbers or strings. A search attribute can have multiple values for
the same object. A search can be done for one or more of these
values. For example, a pathless object can have the attribute name
as "weather" and values can be "sunny", "cloudy", "rainy" etc. If
there are no values specified for a search attribute, a search is
made for the objects having the search attribute, with or without any
values.
Access control for a search attribute is governed by the access
control for the corresponding object. The permissions to read or
write the object's attributes apply to search attributes as well.
To lookup pathless objects, the client sends a list of the search
attributes. A new operation PUTSRCHATTR is added to lookup objects
based on search attributes. The search attributes as well as the
operations are applicable to both pathless objects and Object Sets.
To retrieve or set search attributes, GETATTR and SETATTR are used.
The PUTSRCHATTR operation MUST be used in conjunction with the
READDIR operation to make use of the features provided by the READDIR
operation, namely, a reply cursor, requested set of object attributes
and maximum count of bytes in the reply. The PUTSRCHATTR operation
MUST be immediately followed by a READDIR operation in the same
COMPOUND operation to this effect. The client MUST request the
object filehandles in the bitmap for requested attributes in the
READDIR request. The READDIR reply contains the filehandles of all
the objects matching the search attributes specified in PUTSRCHATTR.
A special search attribute with srchattrname as "objname" of type
SVAL_TYPE_STR MUST always be present for a pathless object and
denotes the name that the object was created with. For Object Sets,
this should have a unique value in the NFS server. For pathless
objects it defaults to an empty string i.e. "".
5.3. Search Attributes Query
The Search Attributes can be queried using the semantics defined in
this section. A simple query is based on the Search Attribute name
and on whether the Search Attribute matches a set of Search Attribute
values. The match can be based on whether the Search Attribute name
has a value that equals the value specified in the query or the match
can also be based on whether the Search Attribute has a value lesser
Dipankar Roy, et al. Expires April 7, 2011 [Page 9]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
than or greater than the value in the query. The lesser than and
greater than comparisons are more effective when the Search Attribute
has a svaltype of a number. Such queries can be logically joined or
chained together using logical primitives such as AND and OR. A NOT
primitive is also present to provide a logical negation of the query,
which will match those objects that do not match the Search Attribute
values specified in the query. Each query has a priority assigned to
it and queries with higher priority will execute earlier. For
example, let's say that there are 3 queries, which are joined like
this: query 1 AND query 2 OR query 3". Suppose query 2 and query 3
have a higher priority than query 1. So the server would execute
this query like this : query 1 AND (query 2 OR query 3), where
brackets indicate a logical grouping and execution of queries of the
same priority.
Some new structured data types are added in this section to define a
Search Attribute query. The type "srelation" determines what is the
nature of the match being done for the Search Attribute and it's
values i.e. whether a match is done for equals, lesser than or
greater than. The type "srchqueryjointype" specifies how two queries
can be logically chained together or if a query needs to be logically
negated. A Search Attribute query is defined as a combination of:
1. A srchattrlist, as defined in the section 5.1 of this RFC
2. A srelation, which specifies how the match for the Search
Attributes inside the srachattrlist and their corresponing values are
done.
3. A srchqueryjoinype called sqjtypenext which specified how the
query should be chained with the next query. The last query in a
chain of queries MUST have this set to SQUERY_NONE.
4. A priority which determines an ordering of the queries. A
priority of 0 SHOULD be considered as the highest priority, followed
by 1 and so on.
5. A flag which tells if the query is a logical NOT. A value of 1
for this flag SHOULD be interpreted as a logical NOT.
Dipankar Roy, et al. Expires April 7, 2011 [Page 10]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
enum srelation {
SRELN_EQUALS = 0;
SRELN_GREATER = 1;
SRELN_LESSER = 2;
};
enum srchqueryjointype {
SQUERY_NONE = 0;
SQUERY_AND = 1;
SQUERY_OR = 2;
};
struct srchquery {
srchattrlist search_attrs;
srelation search_relation;
srchqueryjoinype sqjtypenext;
uint32_t priority;
uint32_t flag;
};
typedef struct srchquery srchquerylist<>;
The flag in srchquery denotes whether the query is a NOT. A value of
1 for the flag means it's a NOT. For example, if a seach attribute
list i.e. srchattrlist has 2 search attributes (A and B), each with
multiple values, and if the flag has a value of 1, it can be
described as NOT ((srchattrnameA (search_relation i.e. EQ, LT, GT)
srchattrvalues) && (srchattrnameB (search_relation i.e. EQ, LT, GT)
srchattrvalues))
The priority in srchquery determines the precedance. For example, in
the searchquery (( A == B) AND (C == D)) OR ( F == G), we want A==B
and C==D computed before F==G. So assign equal priorities to query 1
and query 2, i.e. A==B and C==D and then assign a lower priority to
query 3 i.e. F==G. Similarly to effect the query ( A == B) AND ((C
== D)) OR ( F == G)), query 2 and query 3 are assigned a higher
priority than query 1. Since each query has a priority number, we
can group queries that need to be executed in the same priority
bucket, the same priority number. If the precedance is expressed in
the form of brackets, then the priority is directly proportional to
the number of brackets enclosing a query.
NOT combined with Greater gives us Lesser than or equal to.
Similarly NOT combined with Lesser than gives us Greater than or
equal to. So combining NOT with the search_relation gives the
flexibility to specify these special relations in a query.
Dipankar Roy, et al. Expires April 7, 2011 [Page 11]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
6. New Operations
6.1. Operation 1: PUTOBJROOTFH - Set Object Root Filehandle
SYNOPSIS
- -> (cfh)
ARGUMENT
void;
RESULT
struct PUTOBJROOTFHres {
/* CURRENT_FH: objrootfh */
nfsstat4 status;
};
DESCRIPTION
Replaces the current filehandle with the filehandle that
represents the root of all the Objects Sets that the server
contains.
IMPLEMENTATION
This is the first operator in a NFS request to set the
context for the following operations. A READDIR following a
PUTOBJROOTFH SHOULD list all the Object Sets with respect to
this filehandle. The READDIR operation SHOULD list only Object
Sets and not individual pathless objects.
ERRORS
NFS4ERR_BADSESSION
NFS4ERR_DELAY
NFS4ERR_NOTSUPP
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT
6.2. Operation 2: PUTSRCHATTR: Search for an Object based on Search
Attributes
SYNOPSIS
Dipankar Roy, et al. Expires April 7, 2011 [Page 12]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
(cfh), srchquerylist, -> (cfh)
ARGUMENT
struct PUTSRCHATTRargs {
/* CURRENT_FH: Object Set filehandle */
srchquerylist search_query;
};
RESULT
struct PUTSRCHATTRres {
/* CURRENT_FH: Object Set filehandle */
nfsstat4 status;
};
DESCRIPTION
The PUTSRCHATTR operation searches for objects matching
the search attributes. The scope is the Object Set as
specified in the current filehandle (cfh). Instead of
returning the matching filehandles, it just returns a
status and uses READDIR operation's reply to construct
the proper reply. The READDIR reply is used to return
a variable list of filehandles of all the objects that
matches the search query. The READDIR reply contains the
filehandles for the matching objects in the set of
attributes for the object. The object name is an empty
string by default for pathless objects. A PUTSRCHATTR
in a Compound request MUST be followed by a READDIR.
If the PUTSRCHATTR is not followed by a READDIR, then
NFS4ERR_OP_ILLEGAL MUST be returned by the NFS server.
IMPLEMENTATION
The compound operation for implementing the lookup
based on search attributes is like this:
PUTFH (filehandle of object set), PUTSRCHATTR (search
attributes), READDIR (cookie, verifier, dircount,
maxcount, requested_attrs). It is RECOMMENDED that
dircount be set to a value for zero for this sequence
of operations as clients are not supposed to implement
"ls" based on search attribute lookup.
ERRORS
NFS4ERR_ACCESS
NFS4ERR_ATTRNOTSUPP
Dipankar Roy, et al. Expires April 7, 2011 [Page 13]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
NFS4ERR_BADCHAR
NFS4ERR_BADNAME
NFS4ERR_BADSESSION
NFS4ERR_BADXDR
NFS4ERR_DELAY
NFS4ERR_INVAL
NFS4ERR_IO
NFS4ERR_NAMETOOLONG
NFS4ERR_NOENT
NFS4ERR_NOFILEHANDLE
NFS4ERR_NOTSUPP
NFS4ERR_REP_TOO_BIG
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT
NFS4ERR_STALE
NFS4ERR_WRONG_TYPE
7. Modifications to existing NFSv4.1 operations
7.1. CREATE: Modifications
Object Sets MUST be created with the CREATE call. Pathless objects
are RECOMMENDED to be created with the CREATE call, though they can
also be created with the OPEN call. For an Object Set, an unique
objname is MANDATORY. For a pathless object, objname can be an empty
string, namely, "". In case any other objname is supplied with the
CREATE call for a pathless object, it MAY be allowed. The objname
SHOULD become part of the search attributes for the pathless object
or the Object Set.
7.2. OPEN: Modifications
OPEN with a empty objname SHOULD create a pathless object under the
current filehandle. The current filehandle MUST be the filehandle
for an Object Set.
7.3. LOOKUP: Modifications
Since pathless objects can have a name associated with them, LOOKUP
of an objname under the current filehandle of an Object Set can
return a filehandle which maps to the name. However, there can be
multiple objects which map to the same name and in that case, it MAY
not be correct to return the name of any one of them. So if an
objname maps to a single object filehandle, the LOOKUP operation MAY
return that filehandle. Otherwise, it SHOULD return
NFS4ERR_WRONG_TYPE.
Dipankar Roy, et al. Expires April 7, 2011 [Page 14]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
7.4. READDIR: Modifications
READDIR MUST be used immediately following a PUTSRCHATTR to lookup
pathless objects. If the pathless objects do not have unique names
READDIR will return empty names. If a READDIR operation is used
standalone with current filehandle being set to the Object Set
filehandle, the client MUST request filehandles in the requested set
of attributes and the server SHOULD return filehandles for all the
pathless objects in the Object Set. The READDIR following a
PUTSRCHATTR MUST be used only to return the filehandles and
attributes for the objects matching the query in PUTSRCHATTR. Any
other intended use of READDIR following a PUTSRCHATTR SHOULD NOT be
implemented.
8. Migration and Replication
The RFC 5661 specifies the attributes fs_locations and
fs_locations_info that can be used for migration and replication.
For details, please refer to sections 11.9 and 11.10 of RFC 5661.
Pathless objects can use the same attributes for migration and
replication with some minor modifications. The Object Sets which act
as containers for pathless objects are similar to the root path of a
filesystem within a server. Hence, for pathless objects, "rootpath"
and "fs-root" in fs_location4 SHOULD be Object Set names. Similarly
the "fli_rootpath" and "fli_fs_root" for fs_locations_info4 SHOULD
contain Object Set names.
9. Acknowledgements
The authors would like to acknowledge Manjunath Shankararao for
reviews of the various early versions of the draft. Thomas Haynes
and Daniel Muntz have provided additional comments.
10. IANA Considerations
This memo includes no request to IANA.
11. Security Considerations
All considerations from RFC 3530 Section 16 [RFC3530]
12. References
Dipankar Roy, et al. Expires April 7, 2011 [Page 15]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
12.1. Normative References
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010.
12.2. Informative References
[RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989.
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations",
RFC 2624, June 1999.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Dipankar Roy, et al. Expires April 7, 2011 [Page 16]
Internet-Draft draft-dipankar-nfs-pathless-objects October 2010
Authors' Addresses
Dipankar Roy
NetApp
3rd Floor, Fair Winds Block, EGL Software Park,
Bangalore, Karnataka 560071
IN
Phone: +91-99805-99220
Email: dipankar@netapp.com
Mike Eisler
NetApp
5765 Chase Point Circle
Colorado Springs, CO 80919
USA
Phone: +1-719-599-9026
Email: mike@eisler.com
Alex RN
NetApp
3rd Floor, Fair Winds Block, EGL Software Park,
Bangalore, Karnataka 560071
IN
Phone: +91-80-41843352
Email: rnalex@netapp.com
Dipankar Roy, et al. Expires April 7, 2011 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 10:20:25 |