| Internet-Draft | New Attributes for NFSv4.2 | January 2022 |
| Macklem | Expires 19 July 2022 | [Page] |
This document proposes several new recommended attributes that extend the Network File System Version 4, Minor Version 2 protocol (NFSv4.2). All of these new attributes would be read-only, per file system attributes.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this draft occurs on the NFSv4 working group mailing list, archived at https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group information is available at https://datatracker.ietf.org/wg/nfsv4/about/.¶
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 https://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 19 July 2022.¶
Copyright (c) 2022 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Implementation experience with NFSv4.2 has identified that some additional attributes providing per file system information to clients are useful. This document identifies an important set of additional recommended attributes.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document presents an extension to minor version 2 of the NFSv4 protocol as described in [RFC8178]. It describes new OPTIONAL features. NFSv4.2 servers and clients implemented without knowledge of this extension will continue to interoperate with clients and servers that are aware of the extension (whether or not they support it).¶
Note that [RFC7862] does not define NFSv4.2 as non-extensible, so [RFC8178] treats it as an extensible minor version. This Standards Track RFC extends NFSv4.2 but does not update [RFC7862] or [RFC8178].¶
The list of New OPTIONAL attributes appears in Table 1. The meaning of the columns of the table are:¶
| Name | Id | Data Type | Acc | Defined in: |
|---|---|---|---|---|
| supported_ops | 83 | bitmap4 | R | Section 4.1.1 |
| dir_cookie_rising | 84 | bool | R | Section 4.1.2 |
| seek_granularity | 85 | uint64_t | R | Section 4.1.3 |
| mandatory_br_locks | 86 | bool | R | Section 4.1.4 |
| max_xattr_len | 87 | uint64_t | R | Section 4.1.5 |
This bit vector indicates which operations are supported for objects (of the appropriate type) with an fsid matching that of the specified object.¶
The bit vector is a counted array of 32-bit integers used to contain bit values. The position of the integer in the array that contains the bit corresponding to operation n can be computed from the expression (n / 32), and its bit within that integer is (n mod 32), where n is the operation number.¶
Without this attribute, an NFSv4.2 client must attempt an optional operation to determine if the server supports it. This attribute allows the NFSv4.2 client to avoid attempting an optional operation when it is not supported for the file object's file system on the server.¶
This attribute is likely to be particularly helpful in dealing with OPTIONAL attributes whose support is likely to be different for different file systems.¶
This attribute indicates the granularity of unallocated regions for data objects with an fsid matching that of the specified object. Data objects include regular files and, when named attributes are supported, named attributes.¶
0, if the SEEK operation will not return unallocated regions (holes).¶
1, if the SEEK operation will return unallocated regions (holes), but of no fixed granularity¶
> 1, if the SEEK operation will return unallocated regions (holes), which are an exact multiple of this attribute in length.¶
If this attribute is supported for a file system that does not support the SEEK operation, a value of 0 MUST be returned.¶
A NFSv4.2 client can avoid performing RPCs doing the SEEK operation when this attribute is equal 0 or whenever the client can determine that holes greater or equal to the value of this attribute do not exist in the file.¶
TRUE, if byte range locks obtained on data objects with an fsid matching that of the specified object have mandatory semantics potentially affecting IO operations done on overlapping areas. Data objects include regular files and, when named attributes are supported, named attributes.¶
Applications that work with advisory byte range locks will fail with mandatory byte range locks and vice versa. Given that both forms are allowed yet incompatible, it is necessary to provide a way, other than trial-and-error, to determine which form is supported.¶
Further, if a client is doing read/write caching of data blocks using a write back caching policy, the caching requires locking if mandatory byte range locking is being enforced by the server. For this case, the client needs to acquire an exclusive byte range lock for each byte range being cached. If it does not do so, a write-back may fail, due to a conflicting lock having been acquired by a different client. Therefore, a client doing this kind of data block caching needs to know if the server is implementing mandatory byte range locking.¶
The maximum length, in bytes, of the extended attribute that can be set by the SETXATTR operation for file system objects with an fsid matching that of the specified object. The SETXATTR operation is described in the [RFC8276] extension to NFSv4.2.¶
If this attribute is supported for a file system that does not support the SETXATTR operation, a value of 0 MUST be returned.¶
This attribute allows a NFSv4.2 client to avoid attempting a SETXATTR operation when the length of the extended attribute is greater than the maximum specified by this attribute.¶
This section is to be removed before publishing as an RFC.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.¶
Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
Thanks go to David Noveck for his suggestions for improving the draft.¶