> On 28 Oct 2016, at 22:38, Jaromir Dolecek <jdolecek%netbsd.org@localhost> wrote: > > Module Name: src > Committed By: jdolecek > Date: Fri Oct 28 20:38:12 UTC 2016 > > Modified Files: > src/sys/kern: vfs_wapbl.c > src/sys/sys: wapbl.h > src/sys/ufs/ffs: ffs_alloc.c ffs_inode.c ffs_snapshot.c > src/sys/ufs/ufs: ufs_extern.h ufs_inode.c ufs_rename.c ufs_vnops.c > ufs_wapbl.h > > Log Message: > reorganize ffs_truncate()/ffs_indirtrunc() to be able to partially > succeed; change wapbl_register_deallocation() to return EAGAIN > rather than panic when code hits the limit > > callers changed to either loop calling ffs_truncate() using new > utility ufs_truncate_retry() if their semantics requires it, or > just ignore the failure; remove ufs_wapbl_truncate() > > this fixes possible user-triggerable panic during truncate, and > resolves WAPBL performance issue with truncates of large files > > PR kern/47146 and kern/49175 - This change results in "panic: ffs_blkfree_common: freeing free block" if I put a file system under stress (*1). - I suppose not zeroing the blocks to be freed before freeing them makes the life of fsck harder. - Running "brelse(bp, BC_INVAL)" doesn't look OK. Please fix or revert soon. -- J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany) *1 The stress is running the shell script attached. I usually get a panic within less than a minute on a 16-core virtual amd64.
Attachment:
T.sh
Description: Binary data
Attachment:
fsx.c
Description: Binary data