panic: assertion: layer2->zone == zone in hammer_blockmap_free
dillon at apollo.backplane.com
Sun Aug 3 09:45:57 PDT 2008
I wrote a program to track down all records which blew out their
layer2 allocation and ran it. The results are in your
There were quite a few, but every single one that was an inode had
a ctime close to:
Sat Jul 19 00:26:41 2008 (PDT, I think)
Not only records, but often their related B-Tree nodes too. So whatever
caused that freemap corruption occured only on that day.
I think I know what happened, too. There were some commits right around
that time that fixed a case where HAMMER's buffer cache was being
flushed by the kernel on a panic, causing things to really get out
of sync because the volume header's UNDO pointers wouldn't get updated
in that case. We really want to just throw those buffers away. I'll bet
what happened was that you had a crash related to the cross link tests
on a kernel without those fixes, and the kernel flushed out HAMMER's
unsynchronized meta-data and caused the blockmap to get out of sync.
I think it would be prudent for me to do some more crash testing, to
make sure that bug got fixed. The base bug your reported can be
considered closed though!
I've found two more assertions while testing reblocking and pruning
at the same time. One is related to a buffer alias occuring from
the reblocking, panicing in hammer_io_new(). The other is related to
a B-Tree sanity check related to I think the pruner (a window of
opportunity when the B-Tree is deleting a chain of nodes where an
insertion can occur, causing the chain deletion to assert on the node
being unexpectedly non-empty). I should be able to get both fixed
fairly quickly and they shouldn't cause any media corruption.
These are all related to heavy simultanious pruning and reblocking
only, not normal use.
Just in case you are doing that this is a head's up that I am aware
More information about the Bugs