On Apr 27, 2012, at 11:15 AM, Anatol Pomozov < email@hidden> wrote:
If you set VFS_TBLTHREADSAFE, you must do your own locking. You can receive multiple VNOPs for the same vnode at the same time. You are responsible for making sure they all see a consistent state of your file system.
One thing to beware of with VFS_TBLTHREADSAFE is that operations that operate on multiple vnodes (like creating, deleting, renaming a file, directory or symlink) do not hold a lock between the time they look up the vnode(s) and the time they call the multi-vnode VNOP. That means that other operations could have come after the lookup and before the last VNOP.
For example, VNOP_REMOVE gives you a parent vnode, child vnode, and the child's name. By the time you get into VNOP_REMOVE, the child may no longer be a child of the given parent (i.e., it might have moved to some other directory). The child may no longer have the same name (i.e. may have been renamed). The child may have even been deleted since it was looked up. So you have to check whether things are still the same as when they were looked up, and handle the case where things have changed.
Your VNOP_WRITE handler is responsible for updating all of the metadata associated with the write. That means making sure you have allocated enough space to store the data being written, updating the file's size (if needed), and marking the modification date for update. At a minimum, you need to update your internal state for all of this metadata. When you actually write this out to your underlying storage is up to you.
Your VNOP_STRATEGY handler is responsible for receiving the user data associated with a write (or returning user data associated with a read) and transferring it to your underlying storage. Due to caching, the VNOP_STRATEGY can happen at some point after the VNOP_WRITE completes.
I'll bet you're updating the file's size in VNOP_STRATEGY, not in VNOP_WRITE. You should update it in VNOP_WRITE instead; that sounds like what you called a 'fix'; it really is the correct fix for the problem.
-Mark
|