Re: [nfsv4] request for xattr as a WG item

The reasons are mentioned here (http://tools.ietf.org/html/draft-naik-nfsv4-xattrs-01#page-5).

Apart from that, consider a simple case of setting multiple user-defined attributes at once. It requires multiple NFS operations in named attributes to accomplish  what a single setxattr is expected to do. Why would I want to use a sub-standard mechanism to accomplish user defined metadata.

Moreover, as aptly described by Manoj/Marc, subjecting user-defined attributes to close-to-open semantics is an overhead that could clearly be avoided. For the use cases that I'm tracking scale is important part of the consideration and clearly named attributes for these reasons won't be my choice.

HTH.

- Pranoop

-----Original Message-----
From: Tom Haynes [mailto:thomas.haynes@primarydata.com] 
Sent: Monday, October 06, 2014 9:05 PM
To: Erasani, Pranoop
Cc: Matt W. Benjamin; Nico Williams; NFSv4
Subject: Re: [nfsv4] request for xattr as a WG item

On Oct 6, 2014, at 11:23 PM, Erasani, Pranoop <Pranoop.Erasani@netapp.com> wrote:

> I'm yet to fully appreciate the latest changes in the draft, but based on the last WG discussion, I'm in favor of this proposal and support moving forward with xattr as a WG item.
> 
> I see a number of use cases, where customers ask for "tagging" NFS files with user defined metadata. There is a whole new class of storage appliances (object stores) being built with object protocols whole value is in enhancing file with user defined metadata. This allows user-defined metadata optimized placement (e.g. path independence), metadata driven search and retrieval etc. and allows deeper application integration with the NFSv4.x protocol. And as you probably know, that is a good thing.

Why don't named attributes meet these needs?

> 
> Talking with customers, such object-store protocols became popular because, NFS is too much oriented towards POSIX compliance. While I agree that majority of applications run over POSIX, we have seen marked amount of adoption on a number of clients that don't follow POSIX standard. We need to be accommodative of non-POSIX use cases and innovate to cater NFS towards such use cases. As you may also know, a number of requirements that eventually ended up in NFSv4.2 were from non-POSIX use cases.
> 
> That said, I'm happy to contribute a section on use cases for this document.
> 
> On the logistical front, I hope we are not making it a norm to have a separate "use cases document" for each proposal. That should be in the personal draft itself, especially as we are looking at more and more optional features in the spirit of "DOT" minor versions.
> 
> - Pranoop
> 
> -----Original Message-----
> From: nfsv4 [mailto:nfsv4-bounces@ietf.org] On Behalf Of Matt W. 
> Benjamin
> Sent: Monday, October 06, 2014 2:00 PM
> To: Nico Williams
> Cc: NFSv4
> Subject: Re: [nfsv4] request for xattr as a WG item
> 
> Hi,
> 
> That was my interpretation of the foregoing discussion, and I would also support.
> 
> Matt
> 
> ----- "Nico Williams" <nico@cryptonector.com> wrote:
> 
>> The earlier discussions showed that there was consensus for an xattrs 
>> extension, or at least that named attrs have the wrong semantics. It 
>> seems likely to me that a call for consensus will show consensus for 
>> adoption. FWIW, I'm in favor.
>> 
>> Nico
>> --
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Matt Benjamin
> The Linux Box
> 206 South Fifth Ave. Suite 150
> Ann Arbor, MI  48104
> 
> http://linuxbox.com
> 
> tel.  734-761-4689
> fax.  734-769-8938
> cel.  734-216-5309
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4