Re: puffs & netbsd-5 (was VOP_GETATTR: locking protocol change proposal)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Mon, 21 Nov 2011 08:04:46 +0000
Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:

> 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.

I seem to remember you previously writing about using puffs/rump on
netbsd-5, is that still on netbsd-5?

The reason I ask is that I'm seeing various bugs when using psshfs (and
had various problems when mounting CDs using rump_cd9660); at the time
when I corresponded with Pooka about it he told me that it wasn't ready
for production use on netbsd-5 and recommended -current.  One of the
problems is the process can suddenly start to consume as much CPU
time as it can, while operations become real slow or lock.  Another
issue had to do with inconsistencies between the rump-seen state and
actual on-disk state, possibly due to cache invalidation issues or the
like...

A few days back I still had the psshfs process locked in a loop (I
didn't use it often enough to investigate where it loops yet).
This might not be related at all to the locking issues you're having,
though.

Thanks,
-- 
Matt