I took another whack at trying to make sense of the vnode life cycle,
now that hannken@ has helped clarify some things. This one has a
pretty (ha) diagram for all the vnode states and their transition,
too. Fortunately, most of them are not exposed outside the vnode
abstraction.
I also wrote two
On Fri, Feb 28, 2014 at 03:41:33PM +, Taylor R Campbell wrote:
> Nope. After DESTROYING it gets freed. The protocol is this:
>
> 1. When vfs decides to destroy a vnode, it enters DESTROYING.
> 2. During this time, vget returns ENOENT for it.
> 3. VOP_RECLAIM unhooks it from all data str
On Fri, Feb 28, 2014 at 03:41:33PM +, Taylor R Campbell wrote:
> Also, I propose we nix the terms `recycle' and `reclaim' (except for
> VOP_RECLAIM, until we rename it to VOP_DESTROY). When we're done with
> a vnode, we destroy it and free its memory. When we want to grab it
> from the in
On Feb 28, 2014, at 5:41 PM, Taylor R Campbell
wrote:
>
>> Vrecycle() has to change -- I'm currently working on it.
>>
>> What is it supposed to do? I don't understand from the man page
>> description or the uses in-tree.
>
> While the name is bad it gets rid of inactive vnodes while clea
Date: Fri, 28 Feb 2014 17:22:11 +0100
From: "J. Hannken-Illjes"
On Feb 28, 2014, at 4:41 PM, Taylor R Campbell
wrote:
> Actually, I think I may want to change that, so that vget can be done
> under a pserialized read -- i.e., atomics only, no locks or waits. I
> took a look a
On Feb 28, 2014, at 4:41 PM, Taylor R Campbell
wrote:
> First, using an explicit vnode state, v_interlock to inspect or modify,
> looks good.
>
> Actually, I think I may want to change that, so that vget can be done
> under a pserialized read -- i.e., atomics only, no locks or waits. I
> t
Date: Fri, 28 Feb 2014 15:02:41 +0100
From: J. Hannken-Illjes
On Feb 27, 2014, at 7:16 PM, Taylor R Campbell
wrote:
I'm currently short on time but here are some comments and remarks.
Thanks!
First, using an explicit vnode state, v_interlock to inspect or modify,
looks good
On Feb 27, 2014, at 7:16 PM, Taylor R Campbell
wrote:
I'm currently short on time but here are some comments and remarks.
First, using an explicit vnode state, v_interlock to inspect or modify,
looks good.
> Prompted by hannken's recent patch to tweak vnode locking, and because
> I couldn't fi
Prompted by hannken's recent patch to tweak vnode locking, and because
I couldn't figure out what in Cthulhu's name is going on in the mess
that is the vnode life cycle for the umpteenth time I looked at it, I
wrote a draft (attached) of a new vnode life cycle that sorts out all
of the issues I cou
