Subject: Re: Exports list management, take 3
To: None <jmmv84@gmail.com>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 10/12/2005 08:46:57
hi,

> 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.

while you don't care about the cost you added to nfs_check_export? :-)

i think ideally lookup shouldn't be done more than once per filehandle.
ie. only fsid -> netexport.   no mp -> mount_netexport_pair or fsid -> mp.

btw, isn't it better to coalesce mount_netexport_pair into netexport?

> 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...)

the current implementation merely uses nfs_pub to convert public handle to
the real handle.
although it holds a pointer (nfs_pub.np_mount), it is not used heavily.

YAMAMOTO Takashi