Re: another wapbl and shapshot issue

[Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>]

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.

You don't have a crash dump from the initial panic ?

-- 
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)