:On Mon, Mar 15, 2010 at 10:13:27AM -0700, Matthew Dillon wrote:
:> We have to figure out what that hammer command that's running is
:> trying to do (thread 7, pid 843). That might give me a hint as
:> to what sort of operation is confusing the cursor.
:
:I don't remember which, but those two hammer processes were
:doing `hammer iostats' and `hammer bstats'.
Shoot. That can't hurt anything. I was hoping there'd be a
hammer cleanup running somewhere but those are the only two
hammer user processes.
So maybe this isn't related to a collision with a hammer cleanup
operation but instead something more conventional.
The hammer cursor is at the correct node, just not at the proper
index within that node.
Ok, I found another clue. The transaction id for the elements
inserted into the node for the other object id is the same as the
transaction id being used to delete the range. That implies that
the operation which inserted those elements is another flusher thread.
This makes sense. What doesn't make sense is how they managed to get
inserted without the node's index being properly updated.
I found a second place where I have to flag HAMMER_CURSOR_ITERATE_CHECK,
this time in the normal delete path (no special cases other than a
node becoming empty and being destroyed).
I've committed all the patches so far including some related to
Francois's bug report. You can reset and pull the whole mess, or
just apply thte latest patch ec9b6294f7ea2d9365124dd1e50ebe21c78da8b2
to your already patched test system.
Oh, p.s. is the HAMMER filesystem mounted nohistory? If so that would
explain why this second case is getting hit.
-Matt
Matthew Dillon
<dillon@backplane.com>