On 9/22/05, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
> > Hmm... that could work.  But what about the cleanup routine called
> > during unmount?
>
> some kind of lazy g/c, maybe?
> i don't think it's a big problem because you can flush all of them
> whenever you update the export list.

Not yet, because the exports list is not updated atomically.  For this to
be possible, a lot of changes in mountd have to be done.

A lazy g/c may work, but I see an efficiency problem.  Whenever you
unmount a file system, if it was publicly exported, you've to call
setpublicfs to unset that export.  If you try to do lazy g/c, the publicly
exported file system may remain pointing to a now unexisting file
system.

To solve this issue, one could add a function to retrieve nfs_pub's
value verifying if its respective mount point disappeared.  Doing this
requires finding a match between the mount list and the list hold by the
nfs_export code, with a cost of O(n^2) given that both lists are
unsorted.  As I see it, nfs_pub may be requested often, so this check
could introduce overhead.

Also, problems may arise if, e.g., a mount point disappears and a new
one is created, both sharing the same mount structure (the same
pointer).  In this case, the check above couldn't detect that the old
mount point disappeared, so nfs_pub information could be inconsistent.
(I may be understanding this whole thing completely...)

Despite these problems, lazy initialization may be a good idea.  It could
save some memory bytes by not allocating structures until really
needed.  Mmm...

--
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/