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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:> 
:>    Definitely worth uploading.
:
:Uploaded as ~y0nean1/crash/{kern,vmcore}.4 on leaf.

    This helps a lot.  I think I see what is going on finally, the other
    fixes have made it more apparent.

    What is happening is that the record deletion updates the mirror_tid
    in the B-Tree recursively going upwards, during which the original
    cursor is unlocked.  The unlocked cursor winds up getting moved to
    a parent (internal) B-Tree node which is fine, but then a new record
    is inserted before the cursor is re-locked.

    Because the cursor got moved to an internal node the new insertion can
    get in between the cursor's position and the original range that was
    being scanned.  The unexpected record then causes the assertion.

    I'll have another patch for you to try in a day or two.  I have several
    solutions in mind but I want to try to find the one that is minimally
    invasive for the release.  Basically either (1) Unlocked cursors which
    have to be moved into a parent node can't track and require a
    relookup.  Or (2) when moving an unlocked cursor into its parent the
    cursor's index in the parent must also be bumped to prevent insertions
    from being able to wiggle their way in.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>