Re: another wapbl and shapshot issue

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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 <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--