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

["McDonald, Alex" <[e-mail]>]

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?

> 
> >
> > 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".
 

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