Subject: [nfsv4] RFC 7530: Available attributes for READDIR and Absent File Systems

From: Vitaliy Gusev <[email-masked]>
Date: Sat, 20 May 2017 00:07:30 +0300

Hi!

During improving NFS v4 illumos server for READDIR operation I got question
about availability of attributes for READDIR in case of an absent filesystem.

RFC 7530 Section 8.3.2 “READDIR and Absent File Systems” says only about:
fs_locations
rdattr_error
and doesn’t specify other available attributes.

Section 8.3.1 specifies attributes for an absent filesystem but only for GETATTR operation:
fs_locations
fsid
mounted_on_fileid

Do I miss something or RFC 7530 and RFC 5661 don’t have full set of available attributes
for an absent filesystem that can be got in READDIR operation?

———
Thanks,
Vitaliy Gusev

---

From: David Noveck <[email-masked]>
Date: Sun, 21 May 2017 15:26:53 -0400

> for an absent filesystem that can be got in READDIR operation?

These documents do not specify a full list of available attributes for
absent file systems.  The idea is that what attributes might or might not
be available is up to the server-side file system code. The general
expectation is that very little will be available.

In the case in which you are doing a READDIR within the absent file system,
 no attributes can be provided, since the operation is to be failed with
NFS4ERR_MOVED.

The other relevant case for READDIR is one in which the operation is being
done in a directory within a present file system and some of objects within
the directory are the roots of absent file systems.  Given that context,
the document could have been clearer if it had mentioned fsid and
mounted_on_filled which need to be provided  (it is a SHOULD) for GETATTR.
At the time RFC7530 was done we could have made these "SHOULD"s as they are
for GETATTR but we didn't do that since this is not a very important case
and the client has the option to follow up with GETATTR.

As it is, the server MAY return these attributes.  If one is doing a
server-side implementation, it is best to to provide them since they need
to be available for GETATTR.  On the other hand, if one is doing a
client-side implementation, you can't assume they will be present and need
to be prepared to follow up with an OTW GETATTR (which has to specify
fs_locations to prevent it from being rejected).

On May 20, 2017 3:58 PM, "Vitaliy Gusev" <[email-masked]> wrote:

> RFC 7530 Section 8.3.2 “READDIR and Absent File Systems*”* says only
> about:
>
>    - fs_locations
>    -
>
>    rdattr_error
>
>
>    -
>    - fsid
>    -
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: Vitaliy Gusev <[email-masked]>
Date: Mon, 22 May 2017 02:05:01 +0300

> On 21 May 2017, at 22:26, David Noveck <[email-masked]> wrote:
> …
> The other relevant case for READDIR is one in which the operation is being done in a directory within a present file system and some of objects within the directory are the roots of absent file systems.  Given that context, the document could have been clearer if it had mentioned fsid and mounted_on_filled which need to be provided  (it is a SHOULD) for GETATTR.  At the time RFC7530 was done we could have made these "SHOULD"s as they are for GETATTR but we didn't do that since this is not a very important case and the client has the option to follow up with GETATTR.
> 
> As it is, the server MAY return these attributes.  If one is doing a server-side implementation, it is best to to provide them since they need to be available for GETATTR.  On the other hand, if one is doing a client-side implementation, you can’t assume they will be present and need to be prepared to follow up with an OTW GETATTR (which has to specify fs_locations to prevent it from being rejected).

So you specify case when server can return READDIR the same or lesser quantity of attributes as GETATTR
returns. This case is reasonable.

But what if list of attributes returned by READDIR for root of absent filesystem is more widely than GETATTR returns?
In other words, can other attributes than fs_locations, fsid, mounted_on_fileid, rdattr_error
be available for a root of absent filesystem in READDIR reply?

———
Thanks,
Vitaliy Gusev

---

From: David Noveck <[email-masked]>
Date: Mon, 22 May 2017 07:42:14 -0400

> be available for a root of absent filesystem in READDIR reply?

According to the spec. yes.  Realistically, it is hard to come up with a
case where the server would have this information or in which a client
would be prepared to do anything with it.

On Sun, May 21, 2017 at 7:05 PM, Vitaliy Gusev <[email-masked]>
wrote:

> client-side implementation, you can’t assume they will be present and need
> But what if list of attributes returned by READDIR for root of absent
> filesystem is more widely than GETATTR returns?

---

From: Vitaliy Gusev <[email-masked]>
Date: Mon, 22 May 2017 15:27:42 +0300

> On 22 May 2017, at 14:42, David Noveck <[email-masked]> wrote:
> 
> According to the spec. yes.  Realistically, it is hard to come up with a case where the server would have this information or in which a client would be prepared to do anything with it.

It may introduce double-meaning because in this case some attributes might be
obtained only via READDIR but not via GETATTR.

Is it worth preparing Errata for RFC 7530 Section 16.24.4 or Section 8.3.2 with
description that READDIR for an entry cannot return more attributes (except rdattr_error)
than GEATTR returns?

———
Vitaliy Gusev

---

From: Marcel Telka <[email-masked]>
Date: Mon, 22 May 2017 12:45:20 +0000

> would be prepared to do anything with it.

One such example might be the filehandle attribute.  The server should  
have access to it and clients can use it for the subsequent GETATTR  
operation to get fs_locations, for example.

Thanks.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   [email-masked]  |
|                homepage: http://telka.sk/ |
|                jabber:   [email-masked] |
+-------------------------------------------+