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