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

[Matthew Dillon]

:
:I guess this means that the new code in the patch avoided some bad
:condition, right?

    Yes, that validates that the bug related to the rebalancing code
    was real and that the bug fix actually fixed it.

:By the way, I caught a different panic on vkernel.  I think the last
:I ran `hammer cleanup' on /usr/obj was before applying hammer05.patch
:or hammer06.patch to vkernel.
:
:$ ls /usr/obj
:build.log       t
:$ rm -rf /usr/obj/*; sync
:$ panic: assertion: parent != NULL in hammer_cursor_removed_node
:mp_lock = 00000000; cpuid = 0
:Trace beginning at frame 0x5b7dfabc
:panic(5b7dfae0,0,0,58ba7168,5b7dfaf8) at 0x80dadce
:panic(824684c,8269077,82826b7,5e226588,0) at 0x80dadce
:hammer_cursor_removed_node(58ba7168,0,0,5b7dfc9c,0) at 0x81fe93a
:hammer_btree_do_propagation(58ba7168,0,58ba71b8,58ba71b8,58ba71b8) at 0x81fc4e0
:hammer_btree_do_propagation(0,0,52e22040,b,5b7dfbe8) at 0x81fc4c5
:hammer_btree_delete(5b7dfc9c,1,1,5b7d0114,52e22040) at 0x81fc8c4
:hammer_delete_at_cursor(5b7dfc9c,3,50c7fb30,b,4ae1c1b6) at 0x820b74e
:hammer_ip_delete_record(5b7dfc9c,5e41ead0,50c7fb30,b,4000) at 0x820b9b6
:hammer_ip_delete_range(5b7dfc9c,5e41ead0,0,0,ffffffff) at 0x820bda0
:hammer_sync_inode(5b7d0114,5e41ead0,5b7d0000,5b7d0114,5b7d0000) at 0x82029bd
:hammer_flusher_create(561212f0,0,0,0,0) at 0x8200b47
:Debugger("panic")

    It's possible this will be fixed by the new patch as the propagation
    code uses the recovery mechanism that was patched (I think), or the bug
    fix from the problem corecode reported (also in patch 6).  If you
    have that core I'd like to see it, though, to make sure.

:by sync appears to trigger the panic.  `undo -i' shows a warning like this.
:# undo -i build.log
:HAMMER: WARNING: Missing inode for dirent "build.log@@0x0000000b4d648360"
:        obj_id = 0000000b4d640668, asof=0000000b4d648360, lo=00070000
:load: 0.00  cmd: undo 730 [fifoor] 0.00u 0.00s 0% 820k	<-- ctrl+T
:
:Since there's no important data in /usr/obj (and it's on vkernel anyway),
:I don't mind losing the contents or the history, but will destroying and
:recreating the PFS fix the issue?

    Generally speaking you can ignore missing inode warnings on historical
    entries *unless* the transaction id is on a snapshot boundary (same as
    a snapshot transaction id), in which case there's a problem.

    The warnings can be ignored for any file marked nohistory or if the
    mount is nohistory.  All bets are off for nohistory files/mounts (the
    data is just not in the B-Tree any more).

    There's a second bug related to these missing inode issues and that is
    if the undo code tries to actually open() the file, the file will look
    like a FIFO, as in 'mkfifo' style FIFO, a mistake on my part I should
    probably change it, and then get stuck on the open() until you ^C
    because of that.

    The real issue here is more of a long-standing disconnect between
    the transaction the directory entry is in and the transaction the
    initial laydown of the inode is in.  It is something I need to fix
    but it isn't critical.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>