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