[Port-solaris] Re: EBUSY unmount check

[Andrew Deason]

On Tue, 27 Apr 2010 12:23:13 +0200
"Frank Batschulat (Home)" <Frank.Batschulat@Sun.COM> wrote:

> Sorry for the long time to respond, but I changed gears and no longer
> work in file systems land so new project work takes precedence.

I understand. Thank you for providing such a detailed response!

I'm just sort of thinking aloud below; there's no pressure to continue
reading/responding.

> 	- keep track of all vnode's that have been created via VFS_ROOT(),
> 	  VFS_VGET(), VFS_SWAPVP(), VOP_OPEN(), VOP_CREATE(),
> 	  VOP_LOOKUP(), VOP_MKDIR(), VOP_REALVP() and which are not
> 	  released via VOP_INACTIVE() by adding a corresponding hold to
> 	  the vfs_t via VFS_HOLD()
>         
>         this will be essentially done at the place where you really go
>         and create a new file system object and allocate the
>         corresponding vnode via vn_alloc()
> 
>         This will bump up the vfs_t reference count for every active
>         object.

This is perhaps a little bit stranger for us, since we never call
vn_alloc due to the odd relationship between the OS's vnodes and AFS'
vcaches, and we maintain our own pool of them. I still get what you're
saying though; it's just a little harder to follow step-by-step
instructions.

Speaking in AFS terms, I think what we want to do is a VFS_HOLD in
afs_NewVCache (or afs_NewVCache_int, whatever), which is where we either
pull a vcache/vnode off of the free list, or alloc a new one if the free
list is empty. And we should VFS_RELE in our afs_InactiveVCache, which
is just called from our VOP_INACTIVE handler.

>         - care must be taken if you sustain a cache of file system
>           objects and unreferenced but alife, inactive objects can
>           change identify, ie. if you use vn_invalid()/vn_reinit().
>           those places  also need to deal with VFS_HOLD()/VFS_FREE()

We do have this, but it's pretty much the same place we get them from
anyway. That is, we alloc a chunk of objects up front, and use those as
needed. We only resort to the cache of previously-used objects when we
run out of the "free" ones, but it's done in pretty much the same place
in the code.

>         - you should be implementing a VFS_FREEVFS() callback. once
>           all references to a vfs_t are gone, the filesystem
>           independend vfs layer will invoke VFS_FREEVFS() from
>           VFS_RELE() so that the filesystem depended code can do it
>           any possible still pending internal cleanup work needed and
>           eventually frees the private data vfs_t->vfs_data.

Okay, yeah, it looks like our "shut down afs" routine should just be
called from there, instead of directly from our VFS_UNMOUNT.

> hth, good luck!

Thanks for all of this! I feel better about what's going on now.

-- 
Andrew Deason
adeason@sinenomine.net