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