On Fri, 2017-11-03 at 13:46 -0400, Chuck Lever wrote:
> Before traversing a referral and performing a mount, the mounted-on
> directory looks strange:
>
> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31 1969 dir.0
>
> nfs4_get_referral is wiping out any cached attributes with what was
> returned via GETATTR(fs_locations), but the bit mask for that
> operation does not request any file attributes.
>
> Set the default bits in the GETATTR bitmask to retrieve the usual
> set of object attributes so that the memcpy in nfs4_get_referral can
> fill the attributes in properly.
>
Hmm... So I believe the reason why we didn't do this in the original
implementation is because of RFC7530, Section 8.3.1, which says:
Other attributes SHOULD NOT be made available for absent file
systems, even when it is possible to provide them. The server should
not assume that more information is always better and should avoid
gratuitously providing additional information.
Where "other attributes" means anything other than fs_locations, fsid
and mounted-on-fileid.
IOW: the protocol spec has normative language stating that we should
not expect to be able to retrieve other attributes, and that the server
should not return them.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
