Subject: Re: [nfsv4] Question about EXCLUSIVE4_1

From: David Noveck <[email-masked]>
Date: Thu, 1 Oct 2015 11:05:55 -0400

I misunderstood the intent, having transposed, "former" and "latter" in
"any bits set in the former but not the latter identify the attributes used
to
store the verifier".  I find I can't figure out how this all was intended
to
work and agree with Frank that something doesn't "add up" about this stuff.

Can we hear from implementers, if any, of EXCLUSIVE4_1?  There should
be some since RFC5661 states that support for this is REQUIRED as long
as you are not supporting a persistent reply cache.

On Wed, Sep 30, 2015 at 9:11 PM, Malahal Naineni <[email-masked]> wrote:

> Frank Filz [[email-masked]] wrote:
> > Here are some statements from RFC 5661 that don't quite add up:
> >
> > 5.8.1.14. Attribute 75: suppattr_exclcreat
> >
> > The bit vector that would set all REQUIRED and RECOMMENDED attributes
> > that are supported by the EXCLUSIVE4_1 method of file creation via
> > the OPEN operation. The scope of this attribute applies to all
> > objects with a matching fsid.
> >
> > 18.16.3. DESCRIPTION
> > ...
> >
> > In NFSv4.1, EXCLUSIVE4 has been deprecated in favor of EXCLUSIVE4_1.
> > Unlike EXCLUSIVE4, attributes may be provided in the EXCLUSIVE4_1
> > case, but because the server may use attributes of the target object
> > to store the verifier, the set of allowable attributes may be fewer
> > than the set of attributes SETATTR allows. The allowable attributes
> > for EXCLUSIVE4_1 are indicated in the suppattr_exclcreat
> > (Section 5.8.1.14) attribute. If the client attempts to set in
> > cva_attrs an attribute that is not in suppattr_exclcreat, the server
> > MUST return NFS4ERR_INVAL. The response field, attrset, indicates
> > both which attributes the server set from cva_attrs and which
> > attributes the server used to store the verifier. As described in
> > Section 18.16.4, the client can compare cva_attrs.attrmask with
> > attrset to determine which attributes were used to store the
> > verifier.
> >
> > 18.16.4. IMPLEMENTATION
> > ...
> >
> > After the client has performed a successful exclusive create, the
> > attrset response indicates which attributes were used to store the
> > verifier. If EXCLUSIVE4 was used, the attributes set in attrset were
> > used for the verifier. If EXCLUSIVE4_1 was used, the client
> > determines the attributes used for the verifier by comparing attrset
> > with cva_attrs.attrmask; any bits set in the former but not the
> > latter identify the attributes used to store the verifier. The
> > client MUST immediately send a SETATTR to set attributes used to
> > store the verifier. Until it does so, the attributes used to store
> > the verifier cannot be relied upon. The subsequent SETATTR MUST NOT
> > occur in the same COMPOUND request as the OPEN.
> >
> > These bits taken together suggest that suppattr_exclcreat should NOT
> include
> > the attribute(s) used for the verifier, but it also suggests that if a
> > client sends those attributes on an OPEN/CREATE/EXCLUSIVE4_1 request,
> that
>
> If I understand, attributes used for verifier should not be in
> suppattr_exclcreat list. If a client sends any such verifier attribute,
> the server should return EINVAL.
>
> > the client can determine which attributes were used for the verifier
> because
> > they will be missing from the attrset mask.
>
> I thought it said, they won't be missing in the response attrset mask, but
> rather will be missing in the create request cva_attrs.attrmask.
>
> > On the other hand, it also
> > indicates that if an attribute not part of suppattr_exclcreat is set on
> > OPEN/CREATE/EXCLUSIVE4_1, then the server MUST respond with
> NFS4ERR_INVAL.
> >
> > I'm wondering if in the case of the verifier attributes, they SHOULD be
> > accepted by the server for EXCLUSIVE4_1 even though they aren't in
> > suppattr_exclcreat, but of course will NOT be set and thus not set in the
> > attrset mask. The client can then EITHER use suppattr_exclcreat to
> determine
> > which required attributes are part of the verifier OR it can compare
> > cva_attrs.attrmask with attrset as described.
> >
> > Frank
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Malahal Naineni <[email-masked]>
Date: Thu, 1 Oct 2015 11:34:03 -0500

Here is NFS ganesha server implementation:

1. atime and mtime attrs are CLEARED from suppattr_exclcreat
2. atime and mtime are used for the verifier
3. atime and mtime are added to attrset mask in response to exclusive4_1
   open request.

Note that attrset in response will have atime/mtime set for both
exclusive4 and exclusive4_1 type of open requests.

Regards, Malahal.

David Noveck [[email-masked]] wrote:
>    "any bits set in the former but not the latter identify the attributes
>    used to
>    On Wed, Sep 30, 2015 at 9:11 PM, Malahal Naineni <[1][email-masked]>
>    wrote:
> 
>      Frank Filz [[2][email-masked]] wrote:
>      > [3]https://www.avast.com/antivirus
>      >
>      > [4][email-masked]
>      > [5]https://www.ietf.org/mailman/listinfo/nfsv4
>      >
> 
>      [6][email-masked]
>      [7]https://www.ietf.org/mailman/listinfo/nfsv4
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]
>    3. https://www.avast.com/antivirus
>    4. mailto:[email-masked]
>    5. https://www.ietf.org/mailman/listinfo/nfsv4
>    6. mailto:[email-masked]
>    7. https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Frank Filz" <[email-masked]>
Date: Thu, 1 Oct 2015 09:49:38 -0700

> From: David Noveck [mailto:[email-masked]]
> Sent: Thursday, October 1, 2015 8:06 AM
> To: Malahal Naineni <[email-masked]>
> Cc: Frank Filz <[email-masked]>; [email-masked]
> Subject: Re: [nfsv4] Question about EXCLUSIVE4_1
> 
> I misunderstood the intent, having transposed, "former" and "latter" in "any
> bits set in the former but not the latter identify the attributes used to store
> the verifier".  I find I can't figure out how this all was intended to work and
> agree with Frank that something doesn't "add up" about this stuff.
> 
> Can we hear from implementers, if any, of EXCLUSIVE4_1?  There should be
> some since RFC5661 states that support for this is REQUIRED as long as you
> are not supporting a persistent reply cache.

I was prompted to re-read more carefully... I managed to reverse attrset and cva_attrs.attrmask in my mind.

The RFC actually says that attrset will be cva_attrs.attrmask supplemented with the attrs used for the verifier.

Thanks

Frank

> > that are supported by the EXCLUSIVE4_1 method of file creation via the
> > OPEN operation. The scope of this attribute applies to all objects
> > with a matching fsid.
> >
> > 18.16.3. DESCRIPTION
> > ...
> >
> > for EXCLUSIVE4_1 are indicated in the suppattr_exclcreat (Section
> > 5.8.1.14) attribute. If the client attempts to set in cva_attrs an
> > attribute that is not in suppattr_exclcreat, the server MUST return
> > NFS4ERR_INVAL. The response field, attrset, indicates both which
> > attributes the server set from cva_attrs and which attributes the
> > server used to store the verifier. As described in Section 18.16.4,
> > the client can compare cva_attrs.attrmask with attrset to determine
> > which attributes were used to store the verifier.
> >
> > 18.16.4. IMPLEMENTATION
> > ...
> >
> > used for the verifier. If EXCLUSIVE4_1 was used, the client determines
> > the attributes used for the verifier by comparing attrset with
> > cva_attrs.attrmask; any bits set in the former but not the latter
> > identify the attributes used to store the verifier. The client MUST
> > immediately send a SETATTR to set attributes used to store the
> > verifier. Until it does so, the attributes used to store the verifier
> > cannot be relied upon. The subsequent SETATTR MUST NOT occur in the
> > same COMPOUND request as the OPEN.
> >
> > include the attribute(s) used for the verifier, but it also suggests
> > that if a client sends those attributes on an OPEN/CREATE/EXCLUSIVE4_1
> > request, that
> suppattr_exclcreat list. If a client sends any such verifier attribute, the server
> should return EINVAL.
> 
> > because they will be missing from the attrset mask.
> 
> > indicates that if an attribute not part of suppattr_exclcreat is set
> > on OPEN/CREATE/EXCLUSIVE4_1, then the server MUST respond with
> NFS4ERR_INVAL.
> >
> > I'm wondering if in the case of the verifier attributes, they SHOULD
> > be accepted by the server for EXCLUSIVE4_1 even though they aren't in
> > suppattr_exclcreat, but of course will NOT be set and thus not set in
> > the attrset mask. The client can then EITHER use suppattr_exclcreat to
> > determine which required attributes are part of the verifier OR it can
> > compare cva_attrs.attrmask with attrset as described.
> >
> > Frank

---