Date: Wed, 04 Aug 2004 12:53:03 +0200 From: Eric Masson <e-masson@kisoft-services.com> To: Mailing List FreeBSD Filesystems <freebsd-fs@FreeBSD.org> Subject: mksnap_ffs, time, lor & inconsistencies Message-ID: <86smb3tbsg.fsf@srvbsdnanssv.interne.kisoft-services.com>
next in thread | raw e-mail | index | archive | help
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@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 -+-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86smb3tbsg.fsf>