tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Vnode life cycle: add vnode state
1) Objects vnode and vcache_node always exist together so it makes sense
to merge them into one object. This can be done in two ways:
- Add the current vcache_node elements (hash list, key and flag) to the
vnode.
- Overlay the vnode into vcache_node. This way we also get two views
to vnodes, a public one (struct vnode) visible from file system
implementations and a private one (struct vcache_node) visible from
the VFS subsystem (sys/kern/vfs_*) only.
I prefer the second way, a diff is here:
http://www.netbsd.org/~hannken/vstate/001_merge_vnode_and_vcache_node
2) The state of a vnode is currently determined by its flags
VI_MARKER, VI_CHANGING, VI_XLOCK and VI_CLEAN. These flags are not
sufficient to describe the state a vnode is in. It is for example
impossible to determine if a vnode is currently attaching to a file system.
I propose to replace these flags with a vnode state, one of:
- VN_MARKER: Used as a marker to traverse lists of vnodes, will never change
or appear in a regular vnode operation.
- VN_LOADING: Vnode is currently attaching to its file system and loading
or creatingthe inode.
- VN_ACTIVE: Vnode is fully initialised and useable.
- VN_BLOCKED: Vnode is active but cannot get new references through vget().
- VN_RECLAIMING: Vnode is in process to detach from file system.
- VN_RECLAIMED: Vnode is (no longer) attached to its file system, its dead.
and these operations to work on the vnode state:
- VSTATE_GET(vp): Get the current state.
- VSTATE_CHANGE(vp, from, to): Change state.
- VSTATE_WAIT_STABLE(vp): Wait until the vnode is in stable state, one of
VN_ACTIVE or VN_RECLAIMED.
- VSTATE_ASSERT(vp, state): Assert the current state.
All operations are protected with vp->v_interlock with one exception: to
change state from VN_LOADING vcache.lock is also needed. We can't take
vp->v_interlock while the vnode is loading as it may change while
the file system initialises the node, see uvm_obj_setlock().
Possible state transitions are:
- <undefined> -> VN_LOADING: Node gets allocated in vcache_alloc().
- VN_LOADING -> VN_ACTIVE: Node has been initialised in vcache_get() or
vcache_new() and is ready to use.
- VN_ACTIVE -> VN_RECLAIMING: Node starts disassociation from underlying
file system in vclean().
- VN_RECLAIMING -> VN_RECLAIMED: Node finished disassociation from
underlying file system in vclean().
- VN_ACTIVE -> VN_BLOCKED: Either vcache_rekey*() is changing the vnode key
or vrelel() is about to call VOP_INACTIVE().
- VN_BLOCKED -> VN_ACTIVE: The blocking condition is over.
- VN_LOADING -> VN_RECLAIMED: Either vcache_get() or vcache_new() failed to
associate the underlying file system or vcache_rekey*() drops a vnode
used as placeholder.
A diff adding the state operations is here:
http://www.netbsd.org/~hannken/vstate/002_vnode_state_operations
A diff implementing the state with these operations is here:
http://www.netbsd.org/~hannken/vstate/003_use_vnode_state
Comments or objections anyone?
--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)
Home |
Main Index |
Thread Index |
Old Index