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

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Thu, Oct 22, 2009 at 06:19:01PM -0700, Matthew Dillon wrote:
>     This is a rollup patch which contains all active uncommitted patches
>     for HAMMER.
> 
> 	fetch http://apollo.backplane.com/DFlyMisc/hammer06.patch

Before starting pbulk after booting the patched kernel, I issued
`hammer cleanup /pfs/archives' where I keep packages built by bulkbuild,
and I noticed the following line in the /var/log/messages:

Oct 23 19:15:49 firebolt kernel: HAMMER: Debug: rebalance hit right bndry

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

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")

CPU0 stopping CPUs: 0x000000fe
 stopped
Stopped at      0x823b061:      movb    $0,0x83a7ff4
db>

So far the panic is repeatable, and removing `build.log' followed
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?