mksnap_ffs, time, lor & inconsistencies

[Eric Masson]

Hello,

I'm toying atm with a Dell Powervault 725N (dmesg attached), this box
will be used as a nas, disk layout is the following :

Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/amrd0s1a    248M     76M    152M    33%    /
devfs            1.0K    1.0K      0B   100%    /dev
/dev/amrd0s1e    248M    6.0K    228M     0%    /tmp
/dev/amrd0s1f    2.8G    1.7G    836M    68%    /usr
/dev/amrd0s1d    496M    450K    456M     0%    /var
/dev/amrd1s1d    672G    794M    617G     0%    /vol0

I've just tested snapshots on /vol0 filesystem :
emss at terra:/usr# time mksnap_ffs /vol0 /vol0/.snap/snap0
0.000u 15.634s 32:57.18 0.7%    5+234k 56071+71989io 0pf+0w

/vol0 only contains a copy of /usr/src.

Well, I removed the src directory from vol0 and shut down the machine
via shutdown -p now and everything went fine except i got a lor (similar
to already registered id 006) :
lock order reversal
 1st 0xc26bf948 vnode interlock (vnode interlock) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1906
 2nd 0xc103a100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2223
KDB: stack backtrace:
kdb_backtrace(0,ffffffff,c08b9568,c08ba7b0,c0848a5c) at kdb_backtrace+0x29
witness_checkorder(c103a100,9,c0804b23,8af) at witness_checkorder+0x544
_mtx_lock_flags(c103a100,0,c0804b23,8af) at _mtx_lock_flags+0x5b
_vm_map_lock(c103a0a0,c0804b23,8af) at _vm_map_lock+0x21
vm_map_remove(c103a0a0,c26e1000,c26e9000,dd04dba0,c074cdc1) at vm_map_remove+0x1f
kmem_free(c103a0a0,c26e1000,8000,dd04dbb8,c074eb17) at kmem_free+0x25
page_free(c26e1000,8000,22,8000,dd04dbd0) at page_free+0x29
uma_large_free(c26b33c0) at uma_large_free+0x7f
free(c26e1000,c0881ae0,c2667600,0,c265c000) at free+0xe1
ffs_snapshot_unmount(c265c000) at ffs_snapshot_unmount+0xe7
ffs_flushfiles(c265c000,0,c23c2000) at ffs_flushfiles+0x40
softdep_flushfiles(c265c000,0,c23c2000,c26bf738,0) at softdep_flushfiles+0x1e
ffs_unmount(c265c000,8000000,c23c2000,0,0) at ffs_unmount+0x32
dounmount(c265c000,8000000,c23c2000,410a0a31,8c4052) at dounmount+0x1c4
unmount(c23c2000,dd04dd14,2,1,206) at unmount+0x1e0
syscall(2f,2f,2f,804a72f,8052a51) at syscall+0x217
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c32b7, esp = 0xbfbfe51c, ebp = 0xbfbfe5c8 ---

I then rm'ed the snapshot named snap0 in /vol0/.snap and later shut down
the box via shutdown -p now. syncer process timed out, last message
before stop was "giving up on 41 buffers."

At next reboot, the box fscked all filesystems as none was marked clean

Kernel conf is a plain stock GENERIC from last Friday

Is this an expected behaviour atm, sort of known bug investigated atm ?

And last, is the time used to create a snapshot normal ?

I can offer shell access to the box if needed.

Regards

Eric Masson

-- 
 donc, si tu n'en a rien à foutre tu ne lis pas les mess qui ne te sont
 pas adressés, c'est le problème de poster sur plusieurs forums, tu
 parles au charcutier, et c'est la saucisse qui te répond :-)"
 -+- Sandra in GNU : Si six neuneux scient six saucisses -+-