Subject: RE: Server "Mount" Questions

From: Eric Kadison <[email-masked]>
Date: Fri, 13 Jul 2001 14:12:53 -0700

Brent,

Thanks for the quick reply.  Following up:

> 
> > 2.  Can hostb then export "fsa1" so that a third host, 
> hostc, can see it?
> > (This question is related to the requirement for LOOKUP to 
> span mounted file
> > systems.)  Variations:
> > 
> > 2a. First try: hostc issues to hostb: PUTROOTFH, LOOKUP 
> "mnt" "b5" "a1",
> > GETFH. Will this obtain the valid filehandle for the "a1" 
> directory on
> > hosta?
> > 
> > 2b. Second try:  hostc issues to hostb: PUTROOTFH, LOOKUP 
> "mnt" "b5", GETFH,
> > READDIR.  Will the READDIR result in "a1"?
> 
> Not quite sure what you're looking for here.  Any POSIX 
> compliant client
> of
> a NFSv4 server will have to mirror the mounts it encounters on the
> server, i.e.
> whenever a client crosses a server mountpoint, it'll have to 
> do a mount
> in
> its own namespace.  That'll also apply to crossings from a server's
> pseudo
> filesystem into a real exported filesystem.

Three questions: 
1.  Does the server have any of the responsibility in re-exporting "fsa1"?
Or is this purely a client function?

2.  Is there any reason a server might want to internally provide a mount
(or re-export) function if that host did not also have client functionality?

3.  Is the server supposed to report a different filesystem id for the
pseudo-fs than its real fs?

Thanks,
Eric

---

From: Brent <[email-masked]>
Date: Fri, 13 Jul 2001 15:07:03 -0700

> Or is this purely a client function?

Not quite sure what you're asking here. The client shouldn't have to do
anything different than it would for a normal, non-re-exporting server.
The re-exporting client/server in the middle is that one that has to
do all the work.

> (or re-export) function if that host did not also have client functionality?

Again, not sure what you're asking.  I don't understand the terminology:
is "server" the original server or a re-exporting client/server ?

> pseudo-fs than its real fs?

Ah, that's easy: a pseudo filesystem has to have a different different filesystem
id from the exported filesystems it provides paths to.  Clients need to be
able to detect a change in filesystem id when they cross from a pseudo filesystem
into a real one - so that they can do a mount and preserve POSIX semantics.

	Brent