Subject: [nfsv4] Proposal to address issue 95

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 2 Feb 2007 18:00:01 -0500

The description for GETATTR has a bunch of samll issues in addition
to the contradiction cited in issue 95.  We need to fix them.  Here 
is the current text with some commentary, followed by a proposed 
replacement.

    <t>
      The GETATTR operation will obtain attributes for the file system
      object specified by the current filehandle.  The client sets a bit
in
      the bitmap argument for each attribute value that it would like
the
      server to return.  The server returns an attribute bitmap that
      indicates the attribute values for which it was able to return,

That seems to imply, especially the reference to "was able to return"
that the sets can be different, that GETATTR be asked for an attribute
and not be able to provide it, and not return an error.
 
      followed by the attribute values ordered lowest attribute number
      first.
    </t>
    <t>
      The server must return a value for each attribute that the client
      requests if the attribute is supported by the server. 

That suggests that the only reason the bit is not on is that the
attribute
is not supported by the server, which is consistent with the paragraph
above but in a confusing way, because the fact that the only bits which
may
be in the requested mask but not in the returned mask are because they
are
unsupported attributes, although that fact is not explicit.

Also, it mentions an attribute not being supported by a server but the
set of attributes supported is a per-fs item.
 
                                                              If the
server
      does not support an attribute or cannot approximate a useful value
      then it must not return the attribute value and must not set the
      attribute bit in the result bitmap. 

Here is the big contradiction.  "Or cannot approximate a useful value"
appears to contradict the previous sentence. 

                                           The server must return an
error
      if it supports an attribute but cannot obtain its value. 

OK, now we contradict the (now) previous sentence. 

                                                                In that
case
      no attribute values will be returned.
    </t>
    <t>
      All servers must support the mandatory attributes as specified in
      <xref target="file_attributes">File Attributes</xref>.

They must support these attributes for all file systems.

    </t>

This text does not address the issue of attributes that cannot be
fetched because
a file system is absent.

So here is the proposed replacement:

    <t>
      The GETATTR operation will obtain attributes for the file system
      object specified by the current filehandle.  The client sets a bit
in
      the bitmap argument for each attribute value that it would like
the
      server to return.  The server returns an attribute bitmap that
      indicates the attribute values which it was able to return,
      which will include all attributes requested by the client which
      are attributes supported by the server for the target
      file system.  This bitmap is followed by the attribute values
ordered 
      lowest attribute number first.
    </t>
    <t>
      The server must return a value for each attribute that the client
      requests if the attribute is supported by the server for the
target
      file system.  If the server does not support a particular
attribute 
      on the target file system then it must not return the attribute
value 
      and must not set the attribute bit in the result bitmap.  The
server 
      must return an error if it supports an attribute on the target 
      but cannot obtain its value.  In that case, no attribute values
will 
      be returned.
    </t>
    <t>
      File systems which are absent should be treated as having support
for
      a very small set of attributes as described in 
      <xref target="file_attributes">GETATTR Within an Absent File
System</xref>,
      even if previously, when the file system was present, more
attributes
      were supported.
    </t>
    <t>
      All servers must support the mandatory attributes as specified in
      <xref target="absent_getattr">File Attributes</xref>, for all file
systems,
      with the exception of absent file systems.
    </t>

Comments?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4