DragonFly bugs List (threaded) for 2010-11
Re: panic: assertion: (RB_EMPTY(&ip->rec_tree) && (ip->flags & HAMMER_INODE_XDIRTY) == 0) || (!RB_EMPTY(&ip->rec_tree) && (ip->flags & HAMMER_INODE_XDIRTY) != 0) in hammer_flush_inode_done
:Caught this while running pbulk on an Atom D510, running x86_64 kernel.
:This one is new to me and I haven't seen this one before updating the
:kernel. The current kernel was built from source whose commit hash is
:c6aff4f7f0c74961380763de0bcb5dd49fb7faea, while the previous kernel was
:from c4ce4f88f289f77826fecf470965d7e216274018. No hammer cleanup was
:running when it panicked.
Hmm. Well, the state of the tree and flags as-of the core dump
is fine and would have passed that assertion test, so something
changed between the assertion and the kernel core dump.
Essentially that assertion is saying that XDIRTY should always be
in a synchronized state against whether records exist in ip->rec_tree
I think you may have found a very short race condition where the
XDIRTY flag is not perfectly in-sync with the presence of records
on the RB tree, but I can only guess. It's going to be very rare.
I found one situation where this can happen. If the frontend truncates
a file and calls hammer_rel_mem_record() simultaniously with the backend
finishing a flush operation on the same inode AND a direct write I/O
is in progress (causing the frontend to block) then this case can occur.
Here is a patch to try:
However it may be very difficult to reproduce this bug. What we really
need to do here is just do a run-through on the HAMMER filesystem w/
the patch to make sure I didn't break anything by moving the clearing
of those flags. I'm pretty sure it is ok but I get a bit jittery when
I have to mess with hammer_inode->flags.