On Sun, Nov 20, 2011 at 09:40:35PM +0000, David Holland wrote: > Also, retrieving data protected by a particular lock without holding > it is inherently wrong; if we're going to move the file length out > from under the main vnode lock we'd better do it explicitly.
Yes, this is begging for troubles. FWIW I spent weeks tracking down a file corruption bug on growing giles in PUFFS because VOP_GETATTR operates on an unlocked vnode. If the VOP_GETATTR request follows a not yet completed VOP_FSYNC (as done by ioflush thread), I got toasted: VOP_FSYNC causes PUFFS to send a SETATTR to the filesystem, and on completion VOP_GETATTR gets from the filesystem a file size smaller thant what VOP_FSYNC just set. This cause the file to be truncated by the kernel, and data written between VOP_FSYNC and VOP_GETATTR to be discarded and replaced by a chunk of zeroed bytes. I had to add a lock on file size modification in PUFFS to fix the problem. -- Emmanuel Dreyfus [email protected]
