[Port-solaris] Re: EBUSY unmount check

[Derrick Brashear]

On Tue, Apr 27, 2010 at 12:41 PM, Andrew Deason <adeason@sinenomine.net> wr=
ote:
> 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.
>
>> =A0 =A0 =A0 - keep track of all vnode's that have been created via VFS_R=
OOT(),
>> =A0 =A0 =A0 =A0 VFS_VGET(), VFS_SWAPVP(), VOP_OPEN(), VOP_CREATE(),
>> =A0 =A0 =A0 =A0 VOP_LOOKUP(), VOP_MKDIR(), VOP_REALVP() and which are no=
t
>> =A0 =A0 =A0 =A0 released via VOP_INACTIVE() by adding a corresponding ho=
ld to
>> =A0 =A0 =A0 =A0 the vfs_t via VFS_HOLD()
>>
>> =A0 =A0 =A0 =A0 this will be essentially done at the place where you rea=
lly go
>> =A0 =A0 =A0 =A0 and create a new file system object and allocate the
>> =A0 =A0 =A0 =A0 corresponding vnode via vn_alloc()
>>
>> =A0 =A0 =A0 =A0 This will bump up the vfs_t reference count for every ac=
tive
>> =A0 =A0 =A0 =A0 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.

We could switch to that as the BSDs, Darwin, (DUX) and Linux
approximately all do it.

>
> 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.
>
>> =A0 =A0 =A0 =A0 - care must be taken if you sustain a cache of file syst=
em
>> =A0 =A0 =A0 =A0 =A0 objects and unreferenced but alife, inactive objects=
 can
>> =A0 =A0 =A0 =A0 =A0 change identify, ie. if you use vn_invalid()/vn_rein=
it().
>> =A0 =A0 =A0 =A0 =A0 those places =A0also need to deal with VFS_HOLD()/VF=
S_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.
>
>> =A0 =A0 =A0 =A0 - you should be implementing a VFS_FREEVFS() callback. o=
nce
>> =A0 =A0 =A0 =A0 =A0 all references to a vfs_t are gone, the filesystem
>> =A0 =A0 =A0 =A0 =A0 independend vfs layer will invoke VFS_FREEVFS() from
>> =A0 =A0 =A0 =A0 =A0 VFS_RELE() so that the filesystem depended code can =
do it
>> =A0 =A0 =A0 =A0 =A0 any possible still pending internal cleanup work nee=
ded and
>> =A0 =A0 =A0 =A0 =A0 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.