idnits 2.17.1 draft-faibish-nfsv4-data-reduction-attributes-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2021) is 1041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5661 (ref. '4') (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network File System Version 4 S. Faibish 2 Internet-Draft Cirrus Data Solutions Inc. 3 Intended status: Informational P. Shilane 4 Expires: December 18, 2021 Dell EMC 5 June 18, 2021 7 Support for Data Reduction Attributes in nfsv4 Version 2 8 draft-faibish-nfsv4-data-reduction-attributes-05 10 Abstract 12 This document proposes extending NFSv4 operations to add new 13 RECOMMENDED attributes to be used in the protocol to provide 14 information about the data reduction properties of files. The new 15 data reduction attributes are proposed to allow the client 16 application to communicate to the NFSv4 server data reduction 17 attributes associated with files and directories using new metadata, 18 communicated to the Block Storage data reduction engines. 19 Corresponding new RECOMMENDED attributes are proposed to allow 20 clients and client applications to query the server for data 21 reduction attributes support and allow to get and set data reduction 22 attributes on files and directories. Such data reduction 23 metadata is used as hints to the file server about what type of data 24 reduction to apply. The proposed data reduction attributes include 25 achievable ratios for compression and deduplication plus whether 26 each data reduction technique applies to a file or directory. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of Internet-Draft Shadow Directories can be accessed at 44 https://www.ietf.org/standards/ids/internet-draft-mirror-sites/. 46 This Internet-Draft will expire on December 18, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. New RECOMMENDED attributes . . . . . . . . . . . . . . . . . 8 69 4. File System Support . . . . . . . . . . . . . . . . . . . . . 9 70 5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Data Reduction RECOMMENDED attributes . . . . . . . . . . . . 10 72 7. Protocol Enhancements . . . . . . . . . . . . . . . . . . . . 11 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Normative References . . . . . . . . . . . . . . . . 11 77 10.2 Informative References . . . . . . . . . . . . . . . . 12 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Many NFS servers use expensive solid state media, e.g., NVMe SSDs, 84 complemented by data reduction processing of files to reduce their 85 size on the Block Storage via compression and deduplication, thereby 86 optimizing media usage. This draft considers scenarios in which 87 data reduction processing is performed in Block Storage for NFS 88 servers, i.e., compression and deduplication processing occurs in 89 the background or inline as a consequence of NFS files being 90 written to the Block Storage. In these scenarios, the data reduction 91 engines in Block Storage have limited information about how 92 reducible (compressible and/or deduplicate-able) the data written 93 to NFS is. 95 There is additional strong interest to improve data reduction when 96 using NVMe accessed media and exposing such data attributes to the 97 Block Storage as files or directory attributes over NFS is one 98 means of providing this critical information to Block Storage data 99 reduction engines. 101 There is an expired draft for use of NVMe (over fabric) in accessing 102 a pNFS SCSI Layout [3] which could will be extended to communicate 103 data reduction attributes to NVMe storage. The shortcoming of the 104 current pNFS SCSI NVMe layout is that it has no information related 105 to data reduction attributes. This document discusses potential use 106 of NFSv4 RECOMMENDED attributes as currently standardized in [2], 107 for communicating additional data reduction metadata; a future 108 version of this document will propose updates to the NFSv4 protocol 109 to support this functionality. 111 The purpose of this draft is to define new RECOMMENDED attributes 112 that will allow applications to send richer metadata information 113 to the NFS server in order to optimize Block Storage data 114 reduction engine operations and improve data reduction for data 115 stored by NFS servers. 117 Applications can handle files with different compression and 118 deduplication characteristics and send this information to the data 119 reduction engines. Current applications have defined data reduction 120 characteristics and there are clear definitions for the typical 121 compression and deduplication ratios of some types of data 122 independent of the application that generated the data. For example 123 electronic data analysis (EDA) has no single de facto standard file 124 extension but generates application files with common compression 125 and deduplication characteristics. Knowing that a file is compressed 126 improves the latency and/or throughput of the NFS server by not 127 attempting to further compress the files. An additional example is 128 that NFS backup of files that are already stored on the Block 129 Storage is likely to result in a very high deduplication ratio. 131 1.1 Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [1]. 137 In this document, these words will appear with that interpretation 138 only when in ALL CAPS. Lower case uses of these words are not to be 139 interpreted as carrying RFC-2119 significance. We will refer to the 140 block devices used by the NFS servers as "Block Storage". 142 2. Use Cases 144 Applications can use RECOMMENDED attributes to store metadata 145 together with the files and directories. Metadata regarding data 146 reduction attributes may be available from applications that use 147 different types of files. This metadata may not be directly useful 148 to the file system but is relevant to the compression and 149 deduplication engines used by the Block Storage to improve data 150 reduction. Use of data reduction metadata is not expected to 151 significantly impact I/O latency or throughput (IOPS). 153 File Domain | Block Domain 154 | 155 +-------------+ | +-----------------+ 156 | NFS Server |------------|--------->|Reduction Engine | 157 +------+------+ | +--------+--------+ 158 ^ | | 159 | | | 160 | | v 161 +------+------+ | +--------+--------+ 162 | NFS Client | | | Block storage | 163 +------+------+ | +-----------------+ 164 ^ | 165 | | 166 | | 167 +------+------+ | 168 | Application | | 169 +-------------+ | 170 Figure 1: Data Reduction Domains for NFSv4 172 Figure 1 shows the NFSv4 server configuration, data flow and 173 functionality domains with the data reduction engine in the Block 174 domain and located above the Block Storage. This figure represents 175 NFSv4 without parallel NFS (pNFS) support. In this structure the NFS 176 server can communicate RECOMMENDED attributes as metadata directly 177 to the Reduction Engine via an extension to the interface to Block 178 Storage. 180 In general applications using block devices rely on SCSI protocols 181 to access the data. Although SCSI protocols have a rich API, most 182 communication between hosts and Block Storage, e.g., storage arrays, 183 is in terms of blocks, not files. In contrast, applications use large 184 files to read and write data to and from NFS servers. In general, 185 NFS servers use NFS file systems that are stored on SCSI (or NVMe) 186 devices provisioned from Block Storage, e.g., external storage 187 arrays, as Block Storage but file metadata, e.g., file type and file 188 size, is not transferred to the block array in a explicit manner. 190 An NFS Server might be able to infer data reduction characteristics 191 based on the file type, e.g., a ".mp4" file can be expected to be an 192 MP4 file that contains MPEG-4 content [7]. This is not sufficient 193 due to file content variability, e.g., as a large variety of codecs 194 are used to create MPEG-4 content whose compressibility may vary by 195 codec. To go beyond the file type, the NFS Server could read the 196 file contents to determine compressibility, but this is problematic 197 due to complexity, e.g., the NFS Server may need to parse a 198 significant amount of an MP4 file to obtain the information 199 necessary to understand its compressibility characteristics. This 200 may be impractical if the file is not written to the NFS Server 201 sequentially, and moreover introduces an undesirable dependency on 202 not only the MP4 file format, but also the set of supported codecs 203 that it supports and individual codec characteristics. It is much 204 better to have the application provide information on 205 compressibility, as the application that generates an MP4 file has 206 the information on the file's contents. A mechanism is needed to 207 pass that information to the NFS Server; this document proposes 208 adding and using new RECOMMENDED attributes. 210 So, although the attributes are stored with the files, the current 211 NFSv4 RECOMMENDED attributes specifications [4] indicates that named 212 attributes are accessed by the OPENATTR operation, which accesses a 213 hidden directory of attributes associated with a file system object 214 and contains files whose names represent the RECOMMENDED attributes 215 and whose data bytes are the value of the attribute. If the NFS 216 server extracts the data reduction RECOMMENDED attributes and pass 217 their contents to the Block Storage functionality, the Block Storage 218 reduction engines could parse that content and adapt its data 219 reduction behavior accordingly. 221 File Domain | Block Domain 222 +-------------+ | +------------------+ 223 | |------------------|----->| | 224 | pNFS Server | +-------|----->| Reduction Engine | 225 | | | +----|----->| | 226 +------+------+ | | | +---------+--------+ 227 ^ | | | | 228 | | | | | 229 | | | | v 230 +------+------+ NVMe | | | +--------+--------+ 231 | pNFS Client |----------+ | | | Block storage | 232 | |-------------+ | +-----------------+ 233 +------+------+ SCSI | 234 ^ | 235 | | 236 | | 237 +------+------+ | 238 | Application | | 239 +-------------+ | 240 Figure 2: Data Reduction Domains for pNFS over NVMe or SCSI 242 The RECOMMENDED data reduction attributes may not be supported on 243 all clients and servers. A client may ask for any of these 244 attributes to be returned by setting a bit in the GETATTR request 245 but must handle the case where the server does not return them. A 246 client MAY ask for the set of attributes the server supports and 247 SHOULD NOT request attributes the server does not support. It is 248 expected that servers will support all attributes they comfortably 249 can and only fail to support attributes that are difficult to 250 support in their operating environments. 252 The RECOMMENDED attributes are requested by setting a bit in the 253 bit vector sent in the GETATTR request; the server response includes 254 a bit vector to list what attributes were returned in the response. 255 The current situation is that data reduction done in the block 256 domain lacks critical information that could be provided by the 257 applications in order to improve efficiency of data compression and 258 deduplication. 260 Figure 2 shows another scenario with a pNFS Server and a block pNFS 261 Client that accesses Block storage using either NVMe or SCSI 262 over a network. In this scenario the pNFS Client could send data 263 reduction attributes directly to the reduction engine above the 264 Block storage layer if the block storage protocol (NVMe or SCSI in 265 the figure) supports doing so. The assumption is that the 266 application has additional information related to files types and 267 typical compression and deduplication parameters associated to 268 different file types, e.g., see the above discussion of MPEG-4 269 content. The application can convey this information to the 270 reduction engine to improve the reduction engine efficiency. If the 271 application does not do so, then the user can also add data 272 reduction characteristics for individual files towards improving 273 data reduction efficiency without needing to change the storage 274 array configuration. 276 For this pNFS scenario the application enables sending data 277 reduction parameters to the Block Device using extensions to the 278 SCSI or NVMe protocols. The pNFS Client still needs to pass the 279 data reduction RECOMMENDED attributes to the pNFS Server because 280 the pNFS Client is always allowed to fall back from a pNFS write 281 to an NFS write via the NFS Server; this fallback is similar to the 282 previous case where the NFS Server stores the data reduction 283 attributes associated with each file and directory. A server SHOULD 284 be tolerant of requests for unsupported attributes and simply not 285 return them rather than considering the request an error. 287 For example a video application knows whether a file consists of 288 compressed data or uncompressed data. The application writing the 289 data to the pNFS client can set a RECOMMENDED attribute that will 290 indicate that a file is uncompressed and hence it is likely to be 291 productive for the data reduction engine to reduce the file's size. 293 The pNFS client passes that information via a RECOMMENDED attribute 294 that hints that the file is compressible. The pNFS server will 295 change or add a new data reduction attribute and will transmit the 296 data bytes, that are the value of the attribute, to the 297 Block Storage as a hint that the data is uncompressed. The pNFS 298 client will stream the video using the pNFS NVMe data protocol and 299 the compression engine in the Block Storage will compress the data 300 blocks as long as the uncompressed hint is set in NVMe writes from 301 the pNFS Client. If the attributes data bytes are changed 302 to indicate that the data has been compressed, the compression 303 engine does not compress the incoming blocks. 305 A second example is related to encrypted files that can be neither 306 compressed nor deduplicated in the absence of file copying. For this 307 specific example we envision a not-deduplicatable hint. In this 308 scenario the NFS client sets the deduplication hint to advise to the 309 data reduction engine that deduplication should be enabled for the 310 file. Alternatively if a new file is being written that is not 311 based on modifying an existing file the deduplication hint is set 312 to indicate that deduplication should be disabled. 314 Another use case involves compressed video files and images that 315 are written by video applications. As such files are already 316 compressed, further attempts to compress them are likely to be 317 pointless, and may negatively impact the performance of the NFS 318 Server. 320 An additional scenario involves metadata at the start (header) of 321 the file; an application that did not generate the file may 322 nonetheless be able to access the metadata section in the file and 323 set the RECOMMENDED attributes file based on compression and 324 deduplication found in the file header. The NFS server doesn't 325 have visibility into metadata included in file headers and cannot 326 send file header content to the data reduction engine as separate 327 metadata. Only the user application can access and parse the header 328 and add or update the attribute value when the file is written to 329 the NFS server. 331 Additional examples of known data reduction attributes is 332 implemented in benchmarks such as SPECsfs that is using predefined 333 data reduction attributes. SPECsfs workloads [8] have DR/CR 334 (Deduplication Ratio/Compression Ratio) characteristics that were 335 collected from actual user data. They are as follows: 337 EDA DR/CR=50%/50% 338 SWBUILD DR/CR=0/80% 339 VDI DR/CR=55%/70% 340 DB DR/CR=0/50% 341 VDA DR/CR=0/0 342 IT infrastucture DR/CR=30%/50% 343 Oracle DW DR/CR=15%/70% 344 Oracle OLTP DR/CR=0%/65% 345 Exchange 2010 DR/CR=15%/35% 346 Geoseismic DR/CR=3%/40% 348 Another scenario involves placing files with the same known data 349 reduction characteristics in same directory, where the user or an 350 application sets data reduction RECOMMENDED attribute for the 351 files in a directory that are intended to apply to all files in 352 the directory and possibly also sub-directories. In this case the 353 NFS Server uses the data reduction RECOMMENDED attributes 354 of the directory to inform the data reduction engine of the data 355 reduction characteristics of blocks in all files in that directory. 357 3 New RECOMMENDED attributes 359 RECOMMENDED attributes, [4], are a means to add new attributes 360 associated to file system objects, e.g., files and 361 directories. RECOMMENDED attributes are especially useful when 362 they add information that is not, or cannot be, present in the 363 associated object itself. 365 As RECOMMENDED attributes are stored with the file system objects 366 applications do not need to be concerned about how the attributes 367 are stored internally on the underlying file system. All major 368 operating systems provide various flavors of attributes. 369 Many user space tools allow RECOMMENDED attributes to be included 370 in attributes that need to be preserved when files and directories 371 are updated, moved or copied. The proposed data reduction can be 372 used by the data reduction engines in the Block Storage reduction 373 engine to increase the data reduction and server operations by 374 viewing the RECOMMENDED attributes as hints from the 375 client application regarding file compression and deduplication 376 characteristics. The Block Storage will parse these attributes and 377 change the data reduction methods according to these hints with no 378 need for the file system to know about the data reduction methods 379 used. 381 RECOMMENDED attributes are intended for data needed by applications 382 rather than by an NFS client implementation. NFS implementors are 383 strongly encouraged to define the new data re4duction attributes as 384 RECOMMENDED attributes. RECOMMENDED attributes have long been 385 considered unsuitable for portability because they are inadequately 386 defined and not formally documented by any standard (such as POSIX). 388 However, evidence suggests that RECOMMENDED attributes are widely 389 deployed and their support in modern disk-based file systems is 390 fairly universal. What is different in the new usecase is that the 391 hidden metadata can be retrieved by the NFS server and 392 understood by the data reduction engines of the Block Devices. 394 The data reductiom RECOMMENDED attributes values can be 0 or 100 395 where 0 means "don't do this" hint and 100 is a "do this, but can't 396 predict how much reduction will actually result" hint. They can 397 also take on a percentage value, e.g., from the SPECsfs data shown 398 above. Any regular file or directory may have a set of RECOMMENDED 399 attributes, consisting of attributes Id and whose data bytes are 400 the associated attribute value [4] and data type. 402 As currently specified, the NFS client or server SHOULD interpret 403 the contents of the RECOMMENDED attribute files. This document 404 proposed to add special new attributes that will be specifically 405 used for data reduction. The data reduction RECOMMENDED attributes 406 can be provided by extended attributes supported by most modern 407 file systems and can be retrieved from the local file systems on 408 the client and added to the NFS as new data reduction attributes 409 when files are exported from local file system extended attributes 410 of the files to the RECOMMENDED attributes in NFS. 412 4 File System Support 414 In Linux, ext3, ext4, JFS, XFS, Btrfs, among other file systems 415 support extended attributes. The getfattr and setfattr utilities can 416 be used to retrieve and set xattrs. The names of the extended 417 attributes must be prefixed by the name of the category and a dot; 418 hence these categories are generally qualified as name spaces. 419 In the NTFS file system, extended attributes are one of several 420 supported "file streams" [5]. 422 RECOMMENDED attributes can be retrieved and set through system 423 calls, [6], or shell commands and generally supported by user-space 424 tools that preserve other file attributes. For example, the "rsync" 425 remote copy program will correctly preserve extended attributes 426 between Linux/ext4 and OSX/hfs by stripping off the Linux-specific 427 "user." prefix. 429 5 Namespaces 431 Operating systems may define multiple "namespaces" in which file 432 system objects attributes can be set. Namespaces are more than 433 organizational classes; the operating system may enforce different 434 data reduction policies and allow different reduction 435 characteristics depending on the namespace. 437 The namespace for these attributes may be file system objects 438 accessed by using the GETATTR operation. The OPEN operation returns 439 a filehandle for the file object used by the client ask for any of 440 these attributes to be returned by the client setting a bit in the 441 GETATTR request. 443 6 Data Reduction RECOMMENDED attributes 445 RFC5661 defines RECOMMENDED attributes as opaque byte streams that 446 are associated with a directory or file and referred to by an 447 attribute Id and a value and are understood well enough to warrant 448 support in the NFSv4.1 protocol [4]. RECOMMENDED attributes are 449 intended to be used by client applications as a method to associate 450 application-specific data with a regular file or directory. We will 451 use these RECOMMENDED attributes to add New Data Reduction 452 attributes similar in concept and use to other RECOMMENDED 453 attributes. RECOMMENDED attributes are accessible to the 454 application layer using GETATTR and SETATTR and can be modified 455 by users. Note that some RECOMMENDED attributes are write-only 456 attributes, and are used in special instances of SETATTR. 458 File systems typically define individual attributes using 459 GETATTR and SETATTR operations. There are no clear indications 460 on how RECOMMENDED attributes are mapped to any existing 461 recommended or optional file attributes defined in RFC5661 [2]; 462 as a result, most NFS client implementations ignore 463 application-specified RECOMMENDED attributes. This results in 464 data loss if one copies, over the NFS protocol, a file with data 465 reduction related RECOMMENDED attributes from one file system to 466 another that also supports RECOMMENDED attributes. Although 467 different data reduction engines achieve different levels of 468 reduction these attributes are used by the reduction engines to 469 increase the reduction to different levels for different algorithms. 471 While it should be possible to write guidance about how a client can 472 use the RECOMMENDED attributes mechanism to act as carving out some 473 namespace and specifying locking primitives to enforce 474 atomicity constraints on individual get/set operations, this is 475 problematic for data reduction attributes that are specific to 476 specific applications and file types and not defined by the user. 477 As such there will be mechanisms that will detect the data 478 reduction attributes from the application or from local file 479 system xattrs [6]. The different implementations of the protocol 480 would have to address these attributes based on additional guidance 481 such as reserving some portion of RECOMMENDED attribute namespace 482 for xattr-like [6] functionality. 484 7 Protocol Enhancements 486 This section proposes enhancements to the NFSv4 protocol operations 487 to allow data reduction RECOMMENDED attributes to be queried and 488 modified by clients. A new attribute is added to bitmap4 data type 489 to allow data reduction RECOMMENDED attributes support to be 490 queried. This follows the guidelines specified in [2] with respect 491 to minor versioning. We propose to add 2 bits that will be passed 492 to the reduction engine and used to activate/deactivate the 493 compression and/or the deduplication operations. For example 494 READDIR may be used to get a list of such attributes, and LOOKUP 495 and OPEN may select a particular attribute. Creation of a new 496 RECOMMENDED attribute may be the result of an OPEN specifying file 497 creation. Once an OPEN is done, RECOMMENDED attributes may be 498 examined and changed by normal GETATTR and SETATTR operations 499 using the filehandles and stateid returned by OPEN. The protocol 500 detailes will be provided in the next version of the draft. It is 501 RECOMMENDED that servers support arbitrary data reduction 502 attributes. A client should not depend on the ability to store any 503 RECOMMENDED attributes in the server's file system. 505 8. IANA Considerations 507 All IANA considerations are covered in [4]. 509 9. Security Considerations 511 The additions to the NFS protocol for supporting data reduction 512 RECOMMENDED attributes do not alter the security considerations of 513 the NFSv4.1 protocol [4]. Data reduction hints may enable attacks 514 on Block Storage resources that support the NFS Server. Hinting at 515 more data reduction than is possible may cause excessive data 516 reduction processing, and hinting at less data reduction than is 517 possible, including hinting not to perform any data reduction, may 518 result in consumption of more potentially expensive storage 519 capacity. A future version of this draft will discuss what to do 520 about these possible resource attacks. 522 10. References 524 10.1. Normative References 526 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 527 Levels", BCP 14, RFC 2119, March 1997. 529 [2] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network 530 File System (NFS) Version 4 Minor Version 1 External Data 531 Representation Standard (XDR) Description", RFC 5662, January 532 2010. 534 [4] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network 535 File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, 536 January 2010. 538 10.2 Informative References 540 [3] C. Hellwig, "Using the Parallel NFS (pNFS) SCSI Layout 541 with NVMe", June 2017, 542 https://tools.ietf.org/html/draft-hellwig-nfsv4-scsi-layout- 543 ... nvme-00 545 [5] http://www.freedesktop.org/wiki/CommonExtendedAttributes, 546 "Guidelines for extended attributes". 548 [6] M. Naik, M. Eshel, "File System Extended Attributes in NFSv4" 549 https://datatracker.ietf.org/doc/rfc8276/ 551 [7] ISO/IEC 14496-14 "Information technology - Coding of audio- 552 visual objects - Part 14: MP4 file format" 554 [8] SPEC SFS 2014 SP2 User's Guide, 555 http://spec.org/sfs2014/docs/usersguide.pdf 557 Acknowledgments 559 This draft has attempted to capture the latest industry trends of 560 adding data reduction attributes needed to increase efficiency of 561 newest flash NVMe technology for file servers. New protocols were 562 proposed specific for NVMe media and we were inspired by new drafts 563 proposed by the editor of this draft. 565 Author's Address 567 Sorin Faibish 568 Cirrus Data Solutions Inc. 569 11 Selwyn Road 570 Newton, MA 02461 571 United States of America 573 Phone: +1 617-510-0422 574 Email: sorin.faibish@cdsi.us.com 575 Philip Shilane 576 Dell EMC 577 228 South Street 578 Hopkinton, MA 01774 579 United States of America 581 Phone: +1 908-286-7977 582 Email: philip.shilane@dell.com