On Feb 12, 10:11am, wrstuden@netbsd.org (Bill Studenmund) wrote:
-- Subject: Re: amd/nfs/vgone interaction.

| On Tue, 11 Feb 2003, Christos Zoulas wrote:
| 
| > On Feb 12,  4:41am, fvdl@wasabisystems.com (Frank van der Linden) wrote:
| > -- Subject: Re: amd/nfs/vgone interaction.
| >
| > So are you fixing it, or should I? The larger story is: should VOP_RECLAIM
| > be accessing v_mount? if not, then the code that puts the vnode on the
| > free list should clear it.

But why is VOP_RECLAIM being called on vnodes of unmounted filesystems?
I thought that the vnode list of the mount point contains all the vnodes
that have been allocated for that mount point, and when the filesystem
gets unmounted these get cleaned up. How does a vnode ends up being
on the free list and not on the mount list?

| VOP_RECLAIM accessing v_mount on mounted file systems is fine. On umounted
| ones, no.

Obviously :-)

| Assuming all of the timer cleanup is internal (not waiting for callbacks
| or such that we have to answer to keep others going too), then Frank's
| suggestion of moving the cleanup to VOP_INACTIVATE is fine.
| 
| Other solutions are to:
| 
| 1) when unmounting, vgone all the vnodes on the file system
| 
| or
| 
| 2) when unmounting, flag all the vnodes on the mountpint as "NFS DEAD" -
| set an internal flag. Everything from then on ignores the mount info, and
| waits for the eventual RECLAIM.

But how do you find all the vnodes? Does one have to look in the free list?

christos