[nfsv4] replication and fs_locations

[Tom Haynes <[e-mail]>]

3530 has this to say about replication:

6.1.  Replication

   It is expected that filesystem replication will be used in the case
   of read-only data.  Typically, the filesystem will be replicated on
   two or more servers.  The fs_locations attribute will provide the
   list of these locations to the client.  On first access of the
   filesystem, the client should obtain the value of the fs_locations
   attribute.  If, in the future, the client finds the server
   unresponsive, the client may attempt to use another server specified
   by fs_locations.


The implication is that any server filesystem should be prepared to 
receive a GETATTR {fs_locations}
inquiry.

But if the filesystem is not replicated, what should the server return 
to the client?

1) The empty set?
    - Not sure clients would understand the bitmap being set and no data 
in the results.

2) An error?
    - How do you convey the only error was that there was no other location?
    - Forces client to retransmit compound to get other attributes on 
the filesystem.

3) A set of locations comprised of all the names/IPs assigned to this 
server and the path to the root?
    - This is palatable, but doesn't convey the fact that the only 
location is on this server.

4) We don't error out, we simply do not set the corresponding bit in the 
bitmap.

The last is pretty sane, but I'm not sure how well it balances with the 
language in the description of
GETATTR:

   The GETATTR operation will obtain attributes for the filesystem
   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,
   followed by the attribute values ordered lowest attribute number
   first.

   The server must return a value for each attribute that the client
   requests if the attribute is supported by the server.  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.  The server must return an error
   if it supports an attribute but cannot obtain its value.  In that
   case no attribute values will be returned.

   All servers must support the mandatory attributes as specified in the
   section "File Attributes".

So, assume we have other filesystems on the server which are replicated.

Then we do *support* fs_locations and while we *could* approximate
a useful value, we'd prefer not to do so.

Thus to indicate to the client that there are no replicas, we could simply
not return the attribute value and not set the attribute bit in the result
bitmap.

However, could doing so actually confuse clients?

I.e., a client mounts the root of a server and does a GETATTR with fs_locations.
The server does not set the attribute bit. Does the client understand this
to mean that there are no location information or does it mean that the
server does not support fs_locations as an attribute?

I'm proposing that we agree that if GETATTR {fs_locations} does not set the
attribute bit in the result, we interpret that to solely mean that there
is no location information for the corresponding filesystem at this time.
There could be later or there could be existing location information for
another filesystem on the server.


On a related note, I don't see a separate means to determine if an attribute
is supported or not. On the surface, a GETATTR with a single attribute would
seem to work, but GETATTR is not allowed to return NFS4ERR_NOTSUPP.