DragonFly bugs List (threaded) for 2008-08
DragonFly BSD
DragonFly bugs List (threaded) for 2008-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Aug 2008 09:42:19 -0700 (PDT)

    I wrote a program to track down all records which blew out their
    layer2 allocation and ran it.  The results are in your
    ~crash/checkfree.out.

    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
    of them.

						-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]