panic: assertion: layer2->zone == zone in hammer_blockmap_free

[YONETANI Tomokazu]

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.
> :
> :Cheers.
> 
>     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).

Sure.