andriygapon:avgvfssolarisvsfreebsd

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
andriygapon:avgvfssolarisvsfreebsd [2012/10/14 11:31] – Fix typo. KonstantinBelousovandriygapon:avgvfssolarisvsfreebsd [2016/07/21 11:03] (current) – Move user articles under user heirarchy KubilayKocak
Line 51: Line 51:
   * vdrop - decrements v_holdcnt   * vdrop - decrements v_holdcnt
   * vput/vrele/vunref - decrement v_usecount and v_holdcnt, have different locking pre- and post- conditions   * vput/vrele/vunref - decrement v_usecount and v_holdcnt, have different locking pre- and post- conditions
-    * vput can be be used in VOP_INACTIVE and in that case decrements only v_usecount 
  
 If v_usecount reaches zero in vput/vrele/vunref and the current thread is not already in VOP_INACTIVE, then the VFS code tries to obtain LK_EXCLUSIVE vnode lock (via VOP_LOCK), if not already held, and then calls VOP_INACTIVE. If v_usecount reaches zero in vput/vrele/vunref and the current thread is not already in VOP_INACTIVE, then the VFS code tries to obtain LK_EXCLUSIVE vnode lock (via VOP_LOCK), if not already held, and then calls VOP_INACTIVE.
Line 63: Line 62:
 But the vnode is still valid and could be re-activated. But the vnode is still valid and could be re-activated.
 A filesystem is free to do nothing in VOP_INACTIVE and delay all actions until later (VOP_RECLAIM). A filesystem is free to do nothing in VOP_INACTIVE and delay all actions until later (VOP_RECLAIM).
-Many filesystems detect if the vnode is associated with an unlinked filesystem node and thus can not be re-activated and chose to notify VFS using **vrecycle** call that the vnode can be immediately destroyed. Note that vrecycle doesn't necessarily lead to actual immediate recycling. Outstanding holds may prevent it from happening.+Many filesystems detect if the vnode is associated with an unlinked filesystem node and thus can not be re-activated and chose to ask VFS using **vrecycle** call to destroy vnode immediately, if possible. Note that vrecycle doesn't necessarily lead to actual immediate recycling. Outstanding use references may prevent it from happening. 
 +The immediate reclaim can be forced with vgone() call, if needed.
 Other filesystem may have to perform more complex actions based on their internal design and implementation. Other filesystem may have to perform more complex actions based on their internal design and implementation.
-In the general case the vnode and its filesystem node remain valid and re-usable.+In the general case the vnode and its filesystem node remain valid and re-usable. This way, the caching of the inode pages is implemented.
  
 After the VOP_INACTIVE call is completed v_holdcnt is examined. After the VOP_INACTIVE call is completed v_holdcnt is examined.
Line 75: Line 75:
 In both cases the protocol is generally the same: In both cases the protocol is generally the same:
   * increment the hold count   * increment the hold count
-  * set **VI_DOOMED** flag on the vnode +  * set **VI_DOOMED** flag on the vnode. 
-  * call VOP_RECYCLE +  * call vrecycle() 
-    * note: if VI_OWEINACT is set, then VOP_INACTIVE is invoked before VOP_RECYCLE+    * note: if VI_OWEINACT is set, then VOP_INACTIVE is invoked before VOP_RECLAIM
   * purges the vnode from cache (which could lead to vdrop call if the cache holds the [directory] vnode)   * purges the vnode from cache (which could lead to vdrop call if the cache holds the [directory] vnode)
   * reset the vnode fields to VBAD state   * reset the vnode fields to VBAD state
   * decrement hold count   * decrement hold count
 +
 +Note that both vnode interlock and vnode lock are held while the flag VI_DOOMED flag is set. This means that the recycle cannot be started while any of the locks is owned, if it is not started already.
  
 Once this sequence is started there is no going back. Once this sequence is started there is no going back.
Line 96: Line 98:
  
 As we can see the %%FreeBSD%% strategy offers some advantages: As we can see the %%FreeBSD%% strategy offers some advantages:
-  * role separation between VOP_INACTIVE and VOP_RECYCLE and so potentially simpler logic for both +  * role separation between VOP_INACTIVE and VOP_RECLAIM and so potentially simpler logic for both, together with the centralized handling of vnode cache. 
-  * cached free vnodes allow for faster reactivation when a sequence of operations is execute on the same vnode+  * cached free vnodes allow for faster reactivation when a sequence of operations is executed on the same vnode
   * vnodes less prone to filesystem code bugs or leaks   * vnodes less prone to filesystem code bugs or leaks
 Some disadvantages: Some disadvantages:
Line 109: Line 111:
 Small %%FreeBSD%% summary: Small %%FreeBSD%% summary:
   * if you have a vnode lock, then you are guaranteed that nothing important changes in the vnode state   * if you have a vnode lock, then you are guaranteed that nothing important changes in the vnode state
-  * if you have a reference to a vnode, then you are guaranteed that the vnode stays valid unless forceful unmount happens+  * if you have a reference to a vnode, then you are guaranteed that the vnode stays valid unless a call to vgone() happens, which typically occur due to a forceful unmount request or the underlying device gone.
   * if you have a hold on a vnode, then you are guaranteed that the vnode pointer stays valid, but nothing about the state/validity of the vnode   * if you have a hold on a vnode, then you are guaranteed that the vnode pointer stays valid, but nothing about the state/validity of the vnode
-  * filesystem code may find a vnode associated with a filesystem node to be in a doomed state +  * The %%FreeBSD%% VFS never calls into filesystem with the doomed vnode, if the VOP interface specifies that the vnode lock shall be held. On the other hand, if filesystem code drops the vnode lock, it might find a vnode associated with a filesystem node to be in a doomed state after the relock. 
-  * taking a vnode lock and checking for VI_DOOMED is the only way to get a guaranteed valid (or already recycled) vnode+  * taking a vnode lock or interlock, and checking for VI_DOOMED (without dropping the lock) is the only way to get a guaranteed valid (or already recycled) vnode
  
 Some additional problem: Some additional problem:
Line 137: Line 139:
   * VI_DOOMED is set — forceful reclaim or owed/delayed inactivation (VI_OWEINACT could be set too)   * VI_DOOMED is set — forceful reclaim or owed/delayed inactivation (VI_OWEINACT could be set too)
   * use count is one and VI_OWEINACT is set — owed/delayed inactivation in ''%%vget%%'' before re-activation   * use count is one and VI_OWEINACT is set — owed/delayed inactivation in ''%%vget%%'' before re-activation
 +
 +Calling back into fs code:
 +  * In Solaris it is expected that VN_RELE (or functions that may call it, e.g. dnlc_purge_vfsp) may call into VOP_INACTIVE
 +  * In %%FreeBSD%% VOP_RECLAIM is never invoked directly from vput-ish/vdrop
 +  * In %%FreeBSD%% VOP_INACTIVE is never called directly from vdrop
 +  * in Solaris there are no possible calls into fs code when creating a new vnode
 +  * In %%FreeBSD%% getnewvnode may call VOP_RECLAIM and/or VOP_INACTIVE; but see getnewvnode_reserve
  
  • andriygapon/avgvfssolarisvsfreebsd.1350214279.txt.gz
  • Last modified: 2012/10/14 11:31
  • by KonstantinBelousov