nfs: READDIR for referrals should conform to RFC 7530
NFSv4 server should reply NFS4ERR_MOVED if a client sends READDIR that does not include either of the attributes fs_locations or rdattr_error.
But current implementation returns NFS4_OK in this case.
8.3.2. READDIR and Absent File Systems
A READDIR performed when the current filehandle is within an absent
file system will result in an NFS4ERR_MOVED error, since, unlike the
case of GETATTR, no such exception is made for READDIR.
Attributes for an absent file system may be fetched via a READDIR for
a directory in a present file system, when that directory contains
the root directories of one or more absent file systems. In this
case, the handling is as follows:
o If the attribute set requested includes fs_locations, then the
fetching of attributes proceeds normally, and no NFS4ERR_MOVED
indication is returned even when the rdattr_error attribute is
o If the attribute set requested does not include fs_locations, then
if the rdattr_error attribute is requested, each directory entry
for the root of an absent file system will report NFS4ERR_MOVED as
the value of the rdattr_error attribute.
o If the attribute set requested does not include either of the
attributes fs_locations or rdattr_error, then the occurrence of
the root of an absent file system within the directory will result
in the READDIR failing with an NFS4ERR_MOVED error.
o The unavailability of an attribute because of a file system's
absence, even one that is ordinarily REQUIRED, does not result in
any error indication. The set of attributes returned for the root
directory of the absent file system in that case is simply
restricted to those actually available.
Updated by Vitaliy Gusev over 3 years ago
Also 16.24.4 says:
In some cases, the server may encounter an error while obtaining the
attributes for a directory entry. Instead of returning an error for
the entire READDIR operation, the server can instead return the
attribute 'fattr4_rdattr_error'. With this, the server is able to
communicate the failure to the client and not fail the entire
operation in the instance of what might be a transient failure.
Obviously, the client must request the fattr4_rdattr_error attribute
for this method to work properly. If the client does not request the
attribute, the server has no choice but to return failure for the
entire READDIR operation.
Updated by Vitaliy Gusev over 2 years ago
Add nfs4.0 pcap with both Linux client and server.The nfs-4.0 client (10.42.0.1) calls READDIR with several attributes including rdattr_error attribute. The server (10.42.0.82) replies NFS4_OK with readdir entries:
- for directory "a" - all requested attributes
- for directory "backup" - ERRMOVED in rdattr_error, FSID and mounted_on_fileid
The same behaviour is for illumos server. That conforms to RFC7530. But problem in nfs illumos server is: when neither rdattr_attr nor fs_locations attribute requested (see previously attached file.snoop).
Updated by Vitaliy Gusev over 2 years ago
- File illumos-readdir-without-rdattr_error illumos-readdir-without-rdattr_error added
- File illumos-readdir-with-rdattr_error illumos-readdir-with-rdattr_error added
Attached two pcap files describe problem:
1. illumos-readdir-with-rdattr_error describes how rdattr_error works on READDIR: for referral entry ( has name "backups") it is set to NFS4_ERRMOVED and just one valid attribute is left/set - MOUNTED_ON_FILEID. That conforms to RFC7530.
2. illumos-readdir-without-rdattr_error describes PROBLEM: when rdattr_error is not set in READDIR request, the illumos server (172.16.21.132) replies no error for directory entry name "backups" but WITH SILENT DROPPING all requesting attributes except mounted-on-fileid. That SILENT DROPPING does not conform to RFC7530
Updated by Electric Monk almost 2 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit e6ae04828f7b4574ab7458d343e5c64e42a25850 Author: Vitaliy Gusev <firstname.lastname@example.org> Date: 2018-10-16T15:40:06.000Z 7782 nfs: READDIR for referrals should conform to RFC 7530 Reviewed by: Dan McDonald <email@example.com> Reviewed by: Toomas Soome <firstname.lastname@example.org> Reviewed by: Gerg^V?~E^V?~Q Doma <email@example.com> Approved by: Garrett D'Amore <firstname.lastname@example.org>