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

[Marc Eshel <[e-mail]>]

"McDonald, Alex" <[e-mail]> wrote on 03/26/2015 08:35:02 
AM:

> From: "McDonald, Alex" <[e-mail]>
> To: Marc Eshel/Almaden/IBM@IBMUS
> Cc: "[e-mail]" <[e-mail]>, Spencer Shepler 
> <[e-mail]>
> Date: 03/26/2015 08:35 AM
> Subject: RE: [nfsv4] request for xattr as a WG item
> 
> Some snippage.
> 
> > -----Original Message-----
> > From: Marc Eshel [mailto:[e-mail]]
> > Sent: 24 March 2015 23:11
> > To: McDonald, Alex
> > Cc: Marc Eshel; [e-mail]; Spencer Shepler
> > Subject: RE: [nfsv4] request for xattr as a WG item
> > 
> > "McDonald, Alex" <[e-mail]> wrote on 03/24/2015
> > 03:04:13
> > PM:
> > 
> > > From: "McDonald, Alex" <[e-mail]>
> > > To: Marc Eshel/Almaden/IBM@IBMUS
> > > Cc: "[e-mail]" <[e-mail]>, Spencer Shepler
> > > <[e-mail]>
> > > Date: 03/24/2015 03:04 PM
> > > Subject: RE: [nfsv4] request for xattr as a WG item
> > >
> > > Thanks Marc, that was what I suspected; I hadn't read the draft
> > > proposal. My apologies.
> > >
> > > Specifically addressing
> > https://tools.ietf.org/html/draft-naik-nfsv4-xattrs-01
> > >
> > > 5.1.1 and 5.1.2 assume that the underlying file system is uniform;
> > > either a single file system or a union of file systems that have
> > > maxxattrsize and xattrsize values that match.
> > 
> > yes.
> 
> Is that a reasonable expectation? If we have a union of no xattrs 
> supported and xattrs supported, what should be the source of 
> maxxattrsize and xattrsize?

You get these values from GETATTR, same way you get maxfilesize, so you 
should get it once you crossed to the fs that you are about to set xattr 
to. You will get the right answer for sure if you call GETATTR on the file 
that you are about to set xattr on. 

> 
> > 
> > >
> > > 5.2.4.3 DESCRIPTION (for SETXATTR) describes atomicity
> > > considerations and imposes at least an in-order requirement for
> > > xattr deletions, updates or creations. A successful SETXATTR should
> > > (but is not required to) set time_modify. Although each xattr
> > > operation (update or delete) can be reported as a success or failure
> > > individually, is time_modify updated on partial failure? How does
> > > that reconcile with the use of time_access to detect cache 
incoherency?
> > 
> > We can make it more clear in the draft but any change even partial 
change
> > to xattr SHOULD change the file time_modify and change attributes
> 
> OK, clarification helpful
> 
> > 
> > >
> > > I'll now turn to my questions.
> > >
> [snip]
> > >
> > > b.      Searchability. Can users expect to search for keys or keys
> > > and values, and how would the protocol support it?
> > >
> > > Not without difficulty or at least, it's not clear to me how to
> > > support searching for user.colour="red" without client support, i.e.
> > > requesting attributes that don't match and discarding them. I can't
> > > see a way to inform the server of this type of request. (The whole
> > > area of server side searching for metadata is complex and
> > > problematic, since a lot of the use cases for it require matching
> > > that isn’t for equality.)
> > 
> > Searching for xattr is not part of this draft.
> 
> I understand that and I both misspoke & overgeneralised; I meant update.
> 
> If I have an xattr of user.mynspace.color and I wish to change it to
> "green" if it is "red", then all I have is GETXATTR, a check, 
> followed by SETXATTR as two operations. A compound-like operation 
> isn't possible, but it would be great to support it with SETXATTR 
> (type=equality-match) iff user.mynspace.color="red" then update to 
> "green" else fail the operation. Matching for equality might be the 
> minimum. This would also be an alternative  to "last writer wins".
> 

This is a good idea and we can add it if no one objects, we did get some 
push back for options that are not supported on the application interface. 
Is this option available on any OS for applications to use? 

> 
> Alex McDonald
> Standards & Industry Associations Group
> CTO Office
> NetApp
> [phone] Mobile Phone
> [e-mail]
> twitter: @alextangent
> Follow us: 
>