panic: assertion: leaf->base.obj_id == ip->obj_id in hammer_ip_delete_range

[Matthew Dillon]

: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 at backplane.com>