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

From: Vitaliy Gusev <[email-masked]>
Date: Thu, 16 Aug 2018 02:59:59 +0300

> Marcel Telka <[email-masked]> wrote:
> >Citát David Noveck <[email-masked]> <mailto:[email-masked]&gt>;:
> >> 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?
> >
> > 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.
> 
> 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.

filehandle attribute is not available for an absent filesystem object and GETFH operation returns NFS4ERR_MOVED for this object type.
If READDIR(filehandle) or GETATTR(filehandle) returned valid value for absent filesystem object, it would mean that GETFH also has to return valid value w/o error, but specification says that GETFH must return error NFS4ERR_MOVED for this type of objects.

———
Vitaliy Gusev

---

From: Marcel Telka <[email-masked]>
Date: Thu, 16 Aug 2018 09:45:55 +0200

On Thu, Aug 16, 2018 at 02:59:59AM +0300, Vitaliy Gusev wrote:
> filehandle attribute is not available for an absent filesystem object and

Yes, if you are trying to get the filehandle attribute using GETATTR then it
SHOULD NOT be available for absent filesystem (section 8.3.1 of RFC 7530).

But RFC 7530 is not so clear about the filehandle attribute and READDIR.  IOW,
I believe RFC 7530 does not prohibit READDIR to return filehandle attribute for
an absent object.

Anyway, the filehandle attribute was just an example of such attribute.  Maybe
it is possible to find another attribute that READDIR could successfully return
for an absent object.

> GETFH operation returns NFS4ERR_MOVED for this object type.
> If READDIR(filehandle) or GETATTR(filehandle) returned valid value for absent
> filesystem object, it would mean that GETFH also has to return valid value

How did you concluded that in a case the READDIR(filehandle) would succeed for
an absent filesystem it would mean that GETFH have to succeed too?

> w/o error, but specification says that GETFH must return error NFS4ERR_MOVED
> for this type of objects.

Thanks.

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

---

From: Vitaliy Gusev <[email-masked]>
Date: Wed, 22 Aug 2018 22:38:08 +0300

> On 16 Aug 2018, at 10:45, Marcel Telka <[email-masked]> wrote:
> 

Because this is the same operation with different names (or ways). You can obtain file handle of an object by 3 ways:

   1. LOOKUP; GETFH
   2. LOOKUP; GETATTR(FILEHANDLE)
   3. READDIR(mask[0]: FILEHANDLE)

All operations should produce the same result in case of success because all operations are executed on the same filesystem object. Look at Section 4.2.1:

   As an example, in the case that two different pathnames when
   traversed at the server terminate at the same file system object, the
   server SHOULD return the same filehandle for each path.  This can
   occur if a hard link is used to create two filenames that refer to
   the same underlying file object and associated data.  For example, if
   paths /a/b/c and /a/d/c refer to the same file, the server SHOULD
   return the same filehandle for both pathname traversals.

In our case we have the same path that points to the same file system object.

——
Vitaliy Gusev

---

From: Marcel Telka <[email-masked]>
Date: Fri, 24 Aug 2018 07:12:05 +0200

On Wed, Aug 22, 2018 at 10:38:08PM +0300, Vitaliy Gusev wrote:
> Because this is the same operation with different names (or ways). You can
> obtain file handle of an object by 3 ways:
> 
>    1. LOOKUP; GETFH
> All operations should produce the same result in case of success because all
> operations are executed on the same filesystem object.

Let's assume your wording above is correct.  Then, in a case the GETFH
operation fails with NFS4ERR_MOVED and the READDIR operation succeeds, I see no
contradiction with your wording (yes, you wrote: "in case of success").

> Look at Section 4.2.1:

The paragraph from section 4.2.1 you cited above covers two paths to a single
object, not two ways how to get some information for an object.  So it is
unrelated to this topic, IMHO.

Regards.