[RFC,PATCH 0/4] Dynamic Pseudo Root

J. Bruce Fields bfields at fieldses.org
Mon Dec 10 10:46:23 EST 2007


On Mon, Dec 10, 2007 at 08:56:25AM -0600, Tom Haynes wrote:
> Steve Dickson wrote:
> > Brent Callaghan wrote:
> >   
> >> On Dec 8, 2007, at 6:36 AM, Steve Dickson wrote:
> >>     
> >>>
> >>> So can I assume that Solaris does pump all the exports to a table
> >>> in the kernel?
> >>>       
> >> Yes, BSD and MacOSX do it that way too.  Though I can also see some
> >> advantages in having exports discovered on the fly.
> >>     
> > I kinda like the approach of building the in-kernel export cache 
> > as the exports are accessed. Why pump ton of data into the kernel
> > that may or may not be used?
> >   
> 
> 
> What happens when the server reboots, comes back up, and clients start 
> presenting valid FHs
> to the server?
> 
> How do you detect the need to load the export vs ESTALE?

We extract the part of the filehandle that identifies the filesystem and
pass that up to mountd, which figures out what the corresponding export
is.

> Does the FH have the mount point stored in it somehow?

If I remember correctly, the filehandle includes the inode number of the
export's root directory to handle the case where that's not the root of
the filehandle.

> Or does Linux assume that if a client has a valid FH, then it has access 
> to that file?

No, for obvious reasons.

> And if
> that file is a directory, then it
> 
> And that exposes a performance issue - if it were just mountd requests 
> which had to deal
> with checking to see if exports are loaded, that isn't too bad. But if 
> every NFS v2/v3/v4
> request also has to perform the check, then this might not be welcome.

Right, the results are cached in the kernel.

> Finally, how do you store the state?

Which state?

--b.

> I've done this type of thing in the 
> past and added a
> 2 bit status flag to the in kernel export structure. But that entails 
> you paying the cost of
> all of the rest of structure. (In my case, the number of unloaded 
> exports was very small
> compared to loaded ones.) And that doesn't sound like your vision above.


More information about the NFSv4 mailing list