NFSv4 Working Group M. Naik
Internet Draft M. Eshel
Intended Status: Standards Track IBM Almaden
Expires: August 10, 2014 February 6, 2014
Support for File System Extended Attributes in NFSv4
draft-naik-nfsv4-xattrs-00
Abstract
This document proposes extensions to existing NFSv4 operations to
allow file extended attributes (here forth also referred to as
xattrs) to be manipulated in the protocol. An xattr is a file system
feature that allows opaque metadata, not interpreted by the file
system, to be associated with files and directories and are supported
by many modern file systems. New file attributes are proposed to
allow clients to query the server for xattr support, and get and set
xattrs on file system objects.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Naik, et al. Expires August 10, 2014 [Page 1]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
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
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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Namespaces and Uses . . . . . . . . . . . . . . . . . . . . . . 3
3 Differences with Named Attributes . . . . . . . . . . . . . . . 4
4 Protocol Enhancements . . . . . . . . . . . . . . . . . . . . . 5
4.1 New Attributes . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Attribute Definitions . . . . . . . . . . . . . . . . . . . 5
4.2.1 Attribute 82: xattr_support . . . . . . . . . . . . . . 5
4.2.2 Attribute 83: maxxattrsize . . . . . . . . . . . . . . 5
4.2.3 Attribute 84: xattrsize . . . . . . . . . . . . . . . . 6
4.2.4 Attribute 85: xattrs . . . . . . . . . . . . . . . . . 6
4.2.5 Attribute 86: xattrnames . . . . . . . . . . . . . . . 6
4.3 Extensions to ACE Access Mask Attributes . . . . . . . . . 6
4.4 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Issues and Alternatives . . . . . . . . . . . . . . . . . . . . 7
5.1 New Operations - GETXATTR, SETXATTR . . . . . . . . . . . . 7
5.2 New Operations - GETATTR_PLUS, SETATTR_PLUS . . . . . . . . 8
6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1 Normative References . . . . . . . . . . . . . . . . . . . 9
9.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Naik, et al. Expires August 10, 2014 [Page 2]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
1 Introduction
Extended attributes are a means to associate opaque metadata with
file system objects, typically organized in (name, value) pairs. They
are especially useful when they add information that is not, or
cannot be, present in the associated object itself. All major
operating systems provide various flavors of extended attributes.
Many user space tools allow xattrs to be included in attributes that
need to be preserved when objects are updated, moved or copied.
Extended attributes have long been considered unsuitable for
portability because they are inadequately defined and not documented
by any standard (such as POSIX). Applications that use or share them
need to agree on their format. However, evidence shows that xattrs
are widely deployed and their support in disk-based file systems is
fairly universal.
There are no clear indications on how xattrs can be mapped to any
existing recommended or optional file attributes defined in
[RFC5661]; thereby most NFS implementations ignore application-
specified xattrs. This results in data loss if one copies, over the
NFS protocol, a file with xattrs from one file system to another that
also supports xattrs.
There appears to be relatively strong interest in the community in
exposing xattrs over NFS despite the shortcomings.
This document discusses why the current NFSv4 named attributes as
currently standardized in [RFC5661], are unsuitable for representing
xattrs, and proposes alternate language, adjustment and protocol
mechanisms to support them.
1.1 Terminology
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
2 Namespaces and Uses
Operating systems may define multiple "namespaces" in which xattrs
can be set, but only application-level xattrs that are defined in the
"user" namespace can be considered interoperable across platforms and
vendor implementations. (For example, Linux defines "security",
Naik, et al. Expires August 10, 2014 [Page 3]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
"system", "trusted" and "user" namespaces. The first three are
specific to Linux [1]). As such, this document strongly suggests only
allowing user namespace xattrs to be supported. It is recommended
that at least one application-specific namespace be used before the
attribute, to avoid conflicting use of attributes. Additional text
may be required to restrict the allowed namespaces to user-managed
metadata only, in order to prevent the development of non-
interoperable implementations.
Examples of application-specific xattrs include storing metadata that
tracks what application created the file, a tag to indicate when the
file was last verified by a data integrity scrubber, or a tag to hold
a checksum/crypto hash of the file contents along with the date of
that signature. Xattrs can also be used for decorations or
annotations. For example, a file downloaded from a web server can be
tagged with the URL, which can be convenient if its source has to be
determined in the future. Likewise, an email attachment can when
saved be tagged with the message-id of the email. This will make it
possible to trace the original message. Xattrs can be retrieved and
set through system calls or shell commands and generally supported by
user-space tools that preserve other file attributes.
3 Differences with Named Attributes
[RFC5661] defines named attributes as opaque byte streams that are
associated with a directory or file and referred to by a string name.
Named attributes are intended to be used by client applications as a
method to associate application-specific data with a regular file or
directory. In that sense, xattrs are similar in concept and use to
named attributes, but there are subtle differences.
File systems typically define xattrs operations such as "get" and
"set" as being atomic. Subsequently, xattrs presumably have size
limits ranging from a few bytes to several kilobytes, although this
is not universally defined. Named attributes, on the other hand, are
unbounded data streams and do not impose atomicity requirements.
Individual named attributes are analogous to files, and caching of
the data for these needs to be handled just as data caching is for
ordinary files following close-to-open semantics. Xattrs, on the
other hand, impose caching requirements like other file attributes.
Named attributes and xattrs have different semantics and belong to
disjoint namespaces. As a result, mapping one to another is, at best,
a compromise.
While it should be possible to write guidance about how a client can
use the named attribute mechanism to act like xattrs, such as carving
Naik, et al. Expires August 10, 2014 [Page 4]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
out some namespace and specifying locking primitives, this is
problematic. A client application trying to use xattrs through named
attributes with a server that supported xattrs directly would get a
lower level of service, and could fail to cooperate on a local
application running on the server unless a shim layer was also
implemented on the server side. File systems that already implement
xattrs and named attributes natively would need additional guidance
such as reserving named attribute namespace specifically for
implementation purposes.
4 Protocol Enhancements
This section proposes extensions to the NFSv4 protocol operations to
allow xattrs to be queried and set by clients. New attributes are
proposed to bitmap4 data type to allow xattrs to be queried and set.
This follows the guidelines specified in [RFC5661] with respect to
minor versioning.
4.1 New Attributes
The following RECOMMENDED attributes are proposed. A client can query
the server to determine if xattrs are supported and the maximum size
of the xattrs that are allowed for a file system object. GETATTR and
SETATTR can be used to query and set xattrs on an object.
A client may ask for any of these attributes to be returned by
setting a bit in the GETATTR request but MUST handle the case where
the server does not return them. A client may ask for the set of
attributes the server supports and SHOULD NOT request attributes the
server does not support.
+------------------+----+-------------------+-----+----------------+
|Name | Id | Data Type | Acc | Defined in |
+------------------+----+-------------------+-----+----------------+
| xattr_support | 82 | Boolean | R | Section 4.2.1 |
| maxxattrsize | 83 | uint32_t | R | Section 4.2.2 |
| xattrsize | 84 | uint32_t | R | Section 4.2.3 |
| xattrs | 85 | xattr4<> | R W | Section 4.2.4 |
| xattrnames | 86 | xattrname4<> | R | Section 4.2.5 |
+------------------+----+-------------------+-----+----------------+
4.2 Attribute Definitions
4.2.1 Attribute 82: xattr_support
TRUE, if the object's file system supports extended attributes.
4.2.2 Attribute 83: maxxattrsize
Naik, et al. Expires August 10, 2014 [Page 5]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
Maximum size in bytes of all the extended attributes per object that
the object's file system supports.
4.2.3 Attribute 84: xattrsize
The total size of all the extended attributes of this object in
bytes.
4.2.4 Attribute 85: xattrs
The xattrs attribute contains an array of extended attributes that
are associated with the file system object. Although the client can
get and set xattrs, the server is responsible for using the xattrs
for its own purposes. Any regular file or directory may have xattrs,
each consisting of a name and associated data. Similar to ACLs, the
client can use the OPEN or ACCESS operations to check access without
modifying or reading data or metadata. For SETATTR operation, if the
associated xattrvalue4 has a length of zero, the corresponding xattr
is to be deleted, if it exists. Specific names of attributes will not
be controlled by this document or other IETF Standards Track
documents.
The NFS xattr structure is defined as follows:
typedef utf8str_cis xattrname4;
typedef opaque xattrvalue4<>;
struct xattr4 {
xattrname4 xa_name;
xattrvalue4 xa_value;
};
4.2.5 Attribute 86: xattrnames
The xattrnames is similar to xattrs attribute, except that it only
returns the names of the xattrs for the file system object without
the values. Each xattr is a tuple of the form (name, value).
xattrname4 is a UTF-8 string denoting the xattr name, xattrvalue4 is
a variable length string that identifies the values of a specified
xattr. The NFS client or server must not interpret the value.
4.3 Extensions to ACE Access Mask Attributes
Two new bitmask constants are proposed for the access mask field:
const ACE4_READ_XATTRS = 0x00200000;
const ACE4_WRITE_XATTRS = 0x00400000;
Naik, et al. Expires August 10, 2014 [Page 6]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
Permission to read and write the extended attributes of a file. The
affected operations are GETATTR and SETATTR respectively. No
additional granularity of control is implied by these constants for
server implementations.
4.4 Caching
Similar to other attributes like ACLs, clients may cache xattrs
obtained from the server and use them to avoid subsequent GETATTR
requests. Similarly, such caching is write through in that
modification to file attributes is always done by means of requests
to the server and should not be done locally and should not be
cached. Due to the relative infrequency of xattr updates, it is
suggested that all changes be propagated synchronously.
5 Issues and Alternatives
The proposed bitmap changes treat the object xattrs as a single
attribute, allowing them to be read and written in a single GETATTR
or SETATTR request respectively, similar to other metadata attributes
(such as ACLs). In reality, most file systems allow disparate
metadata to be associated with an object through xattrs, where
combining them into a single entity is unwieldy. For example,
obtaining the value of a single xattr using the bitmap would require
a client implementation to read all the xattrs of the file and find a
match for the one requested. Similarly, replacing or deleting a
single xattr while keeping the others intact would require a client
to read the xattrs first, replacing the existing list with a modified
list that excludes the one to be deleted, and writing out the
remaining xattrs.
5.1 New Operations - GETXATTR, SETXATTR
An alternative to modifying the existing attribute bitmap is to
introduce two separate operations, such as GETXATTR and SETXATTR,
that allow querying and setting of xattrs. This has the advantage of
allowing new functionality that is otherwise difficult to support
with existing operations. For example, GETXATTR could allow listing
all the xattrs names, names with values, or querying the value of a
single name. SETXATTR could allow deleting a single xattr or
replacing a few without modifying the rest.
The disadvantage of defining entirely new operations is with
specifying consistency semantics with respect to existing operations.
For example, modifying a file's xattrs also affects its time_metadata
attribute. Obtaining these through separate RPC operations (GETATTR
and GETXATTR) would violate cache consistency semantics.
Naik, et al. Expires August 10, 2014 [Page 7]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
5.2 New Operations - GETATTR_PLUS, SETATTR_PLUS
Another option is to define new operations, GETATTR_PLUS and
SETATTR_PLUS, that support all the features of the existing NFSv4
GETATTR and SETATTR operations, but allow more information to be
specified to the server, and add information to the format of the
response, in addition to attribute bitmap.
6 Related Work
Extended attributes are supported by many file systems.
In Linux, the ext2, ext3, ext4, JFS, ReiserFS, XFS, Btrfs and OCFS2
file systems support extended attributes. The getfattr and setfattr
utilities can be used to retrieve and set xattrs. The names of the
extended attributes must be prefixed by the name of the category and
a dot; hence these categories are generally qualified as name spaces.
Currently, four namespaces exist: user, trusted, security and system.
Recommendations on how they should be used are published by
freedesktop.org [1].
In FreeBSD, the UFS1 and UFS2 file systems (5.0 and later) and XFS
(8.0 and later) support extended attributes in two namespaces - user
and system. The associated utilities are getextattr, lsextattr,
rmextattr, and setextattr.
Solaris (9 and later) allows files to have extended attributes, but
implements them as "forks".
On Windows NT, limited-length extended attributes are supported by
FAT, HPFS, and NTFS. Additionally, NTFS can support infinite-length
extended attributes in the form of Alternate Data Streams (ADS), a
type of resource fork.
Mac OS X 10.4 and later support extended attributes through open name
spaces enabled through a mount option.
7 Security Considerations
The additions to the NFS protocol for supporting extended attributes
do not alter the security considerations of the NFSv4.1 protocol
[RFC5661].
8 IANA Considerations
There are no IANA considerations in this document. All NFSv4.1 IANA
considerations are covered in [RFC5661].
Naik, et al. Expires August 10, 2014 [Page 8]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
9 References
9.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, January 2010.
[RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
External Data Representation Standard (XDR) Description",
RFC 5662, January 2010.
9.2 Informative References
[1] http://www.freedesktop.org/wiki/CommonExtendedAttributes,
"Guidelines for extended attributes".
Naik, et al. Expires August 10, 2014 [Page 9]
Internet Draft Extended Attributes in NFSv4 February 6, 2014
Authors' Addresses
Manoj Naik
IBM Almaden
650 Harry Rd
San Jose, CA 95120
Phone: +1 408-927-1707
Email: mnaik@us.ibm.com
Marc Eshel
IBM Almaden
650 Harry Rd
San Jose, CA 95120
Phone: +1 408-927-1894
Email: eshel@us.ibm.com
Naik, et al. Expires August 10, 2014 [Page 10]