Subject: [nfsv4] Questions about the fs_root

From: <[email-masked]>
Date: Wed, 18 Aug 2010 09:40:52 -0400

> All
> 
> RFC5661 mentions "the server MUST return an fs_root that is equal to
> the path the client used to reach the object to which the fs_locations
> attribute applies" in the page 260
> 
> My question is how does the server know the path the client used to
> reach the object? Of course, the server can get current path  of
> object and return it as fs_root. However the problem is the current
> path may not be the path the client used to reach it because of
> rename.
> 
> Isn't the client responsibility to record the path? Although the spec
> also mentions "it might not necessarily know that the file system's
> root is located in servA's namespace at /a/b/c" in the page 259.
> However spec mentions how to detect the boundary between present and
> absent filesystem by fsid in the page 231
> 
> Thanks
> Steven

---

From: Tom Haynes <[email-masked]>
Date: Wed, 18 Aug 2010 09:57:21 -0500

>> path may not be the path the client used to reach it because of

The key word in the RFC is "equal". Besides a rename, there could also 
be hard links in the server
filesystem. The server is required to return one path which can get the 
client to the new location.

It doesn't need to know the path the client used to reach the object. 
Look at the example given
in the spec.

The source server knows that the migrated filesystem was located at:

/az/buky/vedi/glagoli

and has been moved to

/izhitsa/fita.

Say the client was accessing "project/runway/model.c" and got the
migration notice. A very braindead client can make the simple translation
the file can now be accessed at the destination server as
"/izhitsa/fita/project/runway/model.c". There is no need to know what
the path had been on the source.

As you allude to below, a smarter client might keep a record of the
server path and try to migrate a bunch of open files based on that
path. And if the path has changed (either due to a rename or hard
links), the client can also get the fsid of the source filesystem.
I.e., it might be better to group the files on the client by
the opaque server fsid rather than some arbitrary path component.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>