Emmanuel Dreyfus <m...@netbsd.org> wrote: > Keeping MAX(rvap->va_size, vp->v_size) in puffs_vnop_getattr() is simple > but it has a drawback with distributed filesystems: a client will not > notify that an open file was shrunk by another client. I think this is > better than deadlocks and data corruption. > > If nobody has a better idea, I will got with this simple fix.
Again, I spoke too fast: even with this simplier fix, it still crashes under low memory. The reason is ioflush sleeping on a VOP_FSYNC to a PUFFS filesystem. Here is its backtrace: sleepq_block cv_wait_sig puffs_msg_wait puffs_msg_wait2 dosetattr flushvncache puffs_vnop_fsync VOP_FSYNC pageflush puffs_vfsop_sync sync_fsync VOP_FSYNC sched_sync At the same time, the filesystem server (perfused) awaits memory to be freed, and here is our deadlock. sleepq_block mtsleep uvm_wait uvm_km_alloc kmem_backend_alloc vmem_xalloc vmem_alloc kmem_alloc putter_fop_write dofilewrite sys_write So we have a completely different bug that the story of zeroed chunks of data: a PUFFS filesystem will cause system deadlock when memory is low, on netbsd-5. Before I start running tests, anyone knows if improvements have been done in -current on that front? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
