On Sun, Apr 10, 2011 at 10:17:39AM +0200, Juergen Hannken-Illjes wrote: > On Fri, Apr 08, 2011 at 10:48:06AM +0200, Manuel Bouyer wrote: > > Hello, > > I ran into another panic "current transaction too big to flush" while using > > snapshots on a 500GB filesystem. This occured when I removed the > > snapshot file, and what's worse, it happens also when the kernel replays > > the log after reboot. > > With more instrumentation in vfs_wapbl.c I found this stack trace at the > > time the log overflows: > > wapbl_add_buf > > bdwrite > > bwrite > > ffs_snapblkfree > > fss_blkfree > > ffs_wapbl_sync_metadata > > wapbl_flush > > wapbl_begin > > ufs_inactive > > VOP_INACTIVE > > vrelel > > ffs_wapbl_replay_finish > > ffs_wapbl_start > > ffs_mountfs > > ffs_mount > > VFS_MOUNT > > ... > > > > to me it looks like the usual way of cutting the transaction in smaller > > pieces > > won't work because we're already in wapbl_begin(). > > Yes. Maybe lower the wl_dealloclim again. > > > Also I wonder if it's OK for wapbl_flush() to cause more data to be > > added to the log. > > It is the way wapbl works. Block deallocations produce more blocks that are > stored in the journal. Its resource estimations are fragile at least.
Hum; if this fails with a 500GB filesystem, I wonder if it'll ever work with multi-terabytes filesystems ... > > You don't have a crash dump from the initial panic ? No, the swap partition is way too small unfortunably. If needed, I probably can make the swap partition larger. -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
