panic: assertion: layer2->zone == zone in hammer_blockmap_free
qhwt+dfly at les.ath.cx
Sat Aug 2 20:54:55 PDT 2008
On Sat, Aug 02, 2008 at 08:24:56PM -0700, Matthew Dillon wrote:
> :/HAMMER is the only HAMMER filesystem on this machine and is mounted without
> :nohistory flags.
> :It experienced two types of major crashes until now: the first one was
> :triggered by an attempt of cross-device link in the middle of July.
> :The other was triggered by network code (reused socket on connect).
> :According to /var/log/messages, the recovery was run only once, though.
> : Jul 19 11:34:52 firebolt kernel: HAMMER(HAMMER) Start Recovery 30000000002c7350 - 30000000002c93f0 (8352 bytes of UNDO)(RW)
> : Jul 19 11:34:53 firebolt kernel: HAMMER(HAMMER) End Recovery
> Ok, I'm not so worried about the net crash. The cross-device link
> crashes (before we fixed it) are interesting... those could be important.
> Did you newfs_hammer the filesystem after the cross-device link crashes
> or is it possible that some cruft from those crashes leaked through to
> current-day? The timestamp in that filesystem's FSID reads July 18th,
> which was right around when you reported that issue.
I newfs_hammer'd before the first cross-device link crash and I haven't
done newfs_hammer after that. And the above message was after the second
cross-device link crash.
> :> * Are the ~500K inodes mostly associated with the slave or unrelated?
> :They are mostly assosiated to /HAMMER/source and /HAMMER/obj.
> I'm crossing my fingers and hoping that the issue was related
> to the cross-device link crashes. If your filesystem still has some
> cruft from those crashes then I will undo the test locally so I can
> reproduce the cross-link crashes and see if I can corrupt the
> filesystem that way.
> If you can, please wipe that filesystem and continue testing fresh,
> and see if you can reproduce that panic (or any bug).
More information about the Bugs