[RFC,PATCH 0/4] Dynamic Pseudo Root
J. Bruce Fields
bfields at fieldses.org
Fri Dec 7 21:02:36 EST 2007
On Fri, Dec 07, 2007 at 07:05:00PM -0500, J. Bruce Fields wrote:
> The kernel currently doesn't currently get the whole export table on
> startup--it just learns bits an pieces of it as new clients make
> requests. To make an in-kernel solution work (especially for READDIR),
> we obviously need to change that. I really hate changing kernel
> interfaces, hence the attraction of doing the whole thing in userspace,
> at least as a prototype.
>
> But maybe there's a way we could make this all work with no or minimal
> changes to the export interface. At a minimum I assume the kernel would
> have to stop looking up the dentry for each new export it learns about,
> as that would require mounting every exported filesystem on nfsd
> startup. That seems like a potential scalability and start-up time
> problem.
So, let's say we stuck with the current interface and used it to load
the export table on startup. Taking Tom's example of about 10,000
exports as a goal we'd like to scale to some day: what that would mean,
with the current kernel interface, is 10,000 calls on startup to
fs/nfsd/export.c:svc_export_parse().
That function takes a string with a path, client name, and export
options. It does a path_lookup() on the path it's given, and stores the
resulting vfsmount and dentry, along with export options and something
representing the client (or group of clients), in the struct svc_export
struct that it creates.
I assume that a path_lookup() that encounters a new filesystem is a
heavier-weight operation than we'd want to do at that point, because,
for example, it may require spinning up a bunch of disks that we
wouldn't have to. Is that correct? If so, we could probably delay it
until it's needed somehow.
If we're passing down the uuid in the export call then that's somewhat
expensive for every export. I'm not sure what to do about that.
The other reason I recall being given for loading the export table
on-demand were that it allows rpc.mountd to do magic stuff on first
access to an export if necessary. I don't know if this is really
important.
--b.
More information about the NFSv4
mailing list