Bug #1972

panic: lockmgr: locking against myself - live dedup

Added by thomas.nikolajsen almost 4 years ago. Updated over 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Using master from today on UP system
I got panic after enabling live dedup (sysctl vfs.hammer.live_dedup=1).

This is on a NFS server; panic happens sometimes almost immediately,
mayby when syncer runs, other times it takes 20 minutes.

Coredump uploaded to leaf as *.11.

-thomas
-
lockmgr(d26389b0,2) at lockmgr+0x382
vn_lock(d26388f8,2,d26066a8,d26388f8,d2606620) at vn_lock+0x21
vget(d26388f8,2,d26066a8,d26388f8,c067d045) at vget+0x43
hammer_get_vnode(d2606620,ceb1b8fc,c26ab370,0,0) at hammer_get_vnode+0x1c1
hammer_dedup_validate(ceb1b930,a,4000,c3b88000,4f2e86a3) at
hammer_dedup_validate+0x98
hammer_ip_add_bulk(d2606620,0,0,c3b88000,4000) at hammer_ip_add_bulk+0xad
hammer_vop_strategy(ceb1bae8,c0380f48,cbf51c00,c2c3d97c,4000) at
hammer_vop_strategy+0x8c7
vop_strategy(cbf51c00,d26388f8,c2c3d9ac) at vop_strategy+0x62
vn_strategy(d26388f8,c2c3d9ac,c2c3db94,c2c3d97c,4000,d26388f8,c2c3d97c) at
vn_strategy+0x96
bawrite(c2c3d97c,c2c3d97c) at bawrite+0xa2
vfsync_bp(c2c3d97c,ceb1bbc0,0,0,c2b672b4) at vfsync_bp+0x155
buf_rb_tree_RB_SCAN(d2638954,c01fb5c8,c01fd6f4,ceb1bbc0,d26389d0) at
buf_rb_tree_RB_SCAN+0xab
vfsync(d26388f8,2,1,0,0) at vfsync+0x11d
hammer_vop_fsync(ceb1bc24,c0380ee8,cbf51c00,d26389b0,12) at
hammer_vop_fsync+0x124
vop_fsync(cbf51c00,d26388f8,2,0,ceb1bca4) at vop_fsync+0x5e
hammer_sync_scan2(ce324de0,d26388f8,ceb1bcc0,11,0) at hammer_sync_scan2+0x36
vmntvnodescan(ce324de0,31,c065fd27,c065fe59,ceb1bcc0) at vmntvnodescan+0x16d
hammer_sync_hmp(ceac0000,6,ce324de0,ce324de0,ceb1bd08) at hammer_sync_hmp+0x48
hammer_vfs_sync(ce324de0,6,ce324de0,5000,4d4035b0) at hammer_vfs_sync+0x36
vfs_sync(ce324de0,6,ce324de0,2) at vfs_sync+0x3b
sync_fsync(ceb1bd34,c0380ee8,c0380c00,12,ce38b1f8) at sync_fsync+0x5f
vop_fsync(c0380c00,ce38b1f8,4,0,ce3bba58) at vop_fsync+0x5e
syncer_thread(0,0,0,0,0) at syncer_thread+0x8c

History

#1 Updated by dillon almost 4 years ago

:Using master from today on UP system
:I got panic after enabling live dedup (sysctl vfs.hammer.live_dedup=1).
:
:This is on a NFS server; panic happens sometimes almost immediately,
:mayby when syncer runs, other times it takes 20 minutes.
:
:Coredump uploaded to leaf as *.11.
:
: -thomas

Yah, this is a known bug. For now you also have to turn on this
sysctl in addition to vfs.hammer.live_dedup if you want to play
with live dedup:

sysctl vfs.hammer.double_buffer=1

Which will bypass the problem for now.

-Matt

#2 Updated by thomas.nikolajsen over 3 years ago

Is it our permanent solution to use enable vfs.hammer.double_buffer
when vfs.hammer.live_dedup is enabled?

Discussion on IRC the other day seemed to indicate this.

If this is the case, we could include it in the code.

And I could document it in hammer.5,
also the description of vfs.hammer.double_buffer sounded
interesting, especially regarding always doing CRC check.

-thomas

#3 Updated by thomas.nikolajsen over 3 years ago

Need for double_buffer for live_dedup documented in
commit 3d048a1b355265d1e42fd5b3c56d3d4e232325d6

Also available in: Atom PDF