[Port-solaris] Re: EBUSY unmount check
Tue, 27 Apr 2010 11:41:24 -0500
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
> - 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
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
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.