Re: [nfsv4] xattr model in draft-naik-nfsv4-xattrs-01?

[Manoj Naik <[e-mail]>]

Nico Williams <[e-mail]> wrote on 10/05/2014 10:06:49 PM:

> From: Nico Williams <[e-mail]>
> To: Christoph Hellwig <[e-mail]>
> Cc: Manoj Naik/Almaden/IBM@IBMUS, [e-mail]
> Date: 10/05/2014 10:06 PM
> Subject: Re: [nfsv4] xattr model in draft-naik-nfsv4-xattrs-01?
>
>
> IMO:
>
>  - for listing attributes the READDIR model should be followed (a
>    pageable list+get operation)

OK, we've been trying to avoid this at least for the first couple of draft
revisions. The current draft (Section 5.2.1) states:

                      In addition, the total size of xattrs exchanged
   between the client and server for get/set operations is limited by
   the channel's negotiated maximum size for requests and responses.

Granted, we probably need to revisit this. Requiring a single xattr get/set
to fit in a single COMPOUND makes the specification much simpler. (This
also seems to be the implicit requirement for other file attributes like
ACLs). Perhaps we can (should?) allow list/getall/setall to follow the
READDIR model.

>
>  - adding new filesystem-relatedsystem calls and [NFS, ...] protocol
>    functionality is a catch-22 kind of deal, and if we always require
>    the other to be present first then the one can't ever happen;
>
>    I'm inclined to say that a get/setallxattrs() should be supported,
>    BUT:
>
>     - it must be clear that it won't be atomic because it can't be
>       atomic

This is documented in the draft (Section 5.3.3.3):

   While the SETXATTR request MAY contain multiple attribute keys and/or
   values to be changed for a file, this does not impose any atomicity
   considerations on the server implementation. If the server cannot
   update all the attributes for the file atomically, it MUST set them
   in the order specified.

I'll make sure this is added for the GETXATTR section as well.

Manoj.

>
>     - because it has to be pageable (and the protocol in general doesn't
>       support atomicity in such cases)
>
> Nico
> --
>