Subject: RE: [nfsv4] Fw: Global namespace and multiple file access protocols

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 2 Jan 2004 12:08:16 -0800

Nico Williams wrote: 
> [Jon Haswell wrote]
> > 2) When a client has started interacting with a server and every time it
> > crosses into a new FS it must virtually query if locations for FS's mounted
> > within this FS should be located via the file serving protocol or
> > externally via LDAP.

> The server may issue referrals at any time and for any directory or
> file, not just at fs cross points.

I don't think so.

Let's suppose that a/b/c is the root of an fs on a given sserver.  So
suppose you get down to the arbitrary (in terms of fs boudaries) 
directory a/b/c/d/e and you return the MOVED error.  Depending on
the fs_root value (the fsid attribute should show the same thing if
the server chooses to return and the client chooses to fetch it),
you will have one of two situations: a/b/c/d/e will be the root of 
a new fs, and thus we have crossed an fs boundary or a/b/c will be
the root of the current fs in which case we haven't.

In the first case, we have a referral at an fs boundary.

In the second case, we still do not have a referral at an arbitrary
directory.  We have migration of the entire fs rooted at a/b/c
to some other server.  The way MOVED is defined, it specifies that
entire fs moves.  In practical terms, this should not be much of
a problem in that if you want to force a referral at an arbitrary 
directory, you can, since the server can create his fs boundaries 
where it wishes, i.e. arbitrarily. 

> The client should query for fsid / fs locations voluntarily anyways so
> that when it crosses a server-side fs boundary it can find all the
> alternative locations of the fs it crossed into.

Yes.

> But NFSv4 referrals need not involve a server-side fs boundary.

It needn't be a real server-side fs boundary, but the cleint has to
see such a boundary, at least in the form of an fs_root values for
fs_locations, or else I don't see how the client can consistently
determine the scope of the migration/referral event.

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Jan 2004 15:01:39 -0600

In a previous reply on the same thread I wrote:

> On Mon, Dec 29, 2003 at 10:35:32AM -0800, Jon Haswell wrote:
[...]
> > Now I don't know if there are some special cases that don't follow this
> > pattern, but this to me says that CIFS and NFS V4 are very similar in that
> > the client goes back to the server returning the error code to find the
> > actual data location (in the NFS V4 case at the FS granularity in the CIFS
> > case at the directory/file level). How the CIFS file server gets the
> > information on where the data now resides I presume would be covered by the
> > 'in Active Directory' comment.
> 
> Minor nit: the NFSv4 referral granularity is also down to the directory/
> file level.

The statement you object to was in relation to this and should have
read:

"The server may issue referrals at any time and for any directory or
file, not just at _server-side_ fs cross points."

I see nothing below that disproves this.  I'm pretty sure that you'd not
want to limit NFSv4 referrals to server-side fs cross-points, which is
what I think Jon thinks is the case.

> In the first case, we have a referral at an fs boundary.

Nit: the server need not have issued a referral (MOVED), letting the
client detect the server-side fs boundary crossing through the fsid/
fs_locations change.

> where it wishes, i.e. arbitrarily. 

The third case, which I referred to indirectly is the case where
a/b/c/d/e doesn't exist on the server but the server knows that it does
exist and where, in which case it issues a referral.

Note that in this case a/b/c/d/e is not a server-side fs cross point --
though in a way it is a boundary, in that a/b/c/d/e cannot exist as a
node of the fs that contains a/b/c/d.

Cheers,

Nico
--