zfs: using, then destroying a snapshot sometimes panics zfs
Stefan Bethke
stb at lassitu.de
Wed Feb 25 13:34:08 PST 2009
Am 18.02.2009 um 07:55 schrieb Stefan Bethke:
> # cd /tank/foo/.zfs
> # ls -l
> ls: snapshot: Bad file descriptor
> total 0
> # cd snapshot
> -su: cd: snapshot: Not a directory
> Trying to umount produces a panic:
> # zfs umount /jail/foo
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0xa8
> fault code = supervisor write data, page not present
> instruction pointer = 0x8:0xffffffff802ee565
> stack pointer = 0x10:0xfffffffea29c39e0
> frame pointer = 0x10:0xfffffffea29c39f0
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 51383 (zfs)
> [thread pid 51383 tid 100298 ]
> Stopped at _sx_xlock+0x15: lock cmpxchgq %rsi,0x18(%rdi)
> db> bt
> Tracing pid 51383 tid 100298 td 0xffffff00a598e720
> _sx_xlock() at _sx_xlock+0x15
> zfsctl_umount_snapshots() at zfsctl_umount_snapshots+0xa5
> zfs_umount() at zfs_umount+0xdd
> dounmount() at dounmount+0x2b4
> unmount() at unmount+0x24b
> syscall() at syscall+0x1a5
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800f412fc, rsp =
> 0x7fffffffd1a8, rbp = 0x801202300 ---
> db> call doadump
The script I am using used to do:
1. create snapshot
2. copy data with rsync from the snapshot
3. destroy snapshot
Sometime after (anywhere between minutes an hours), the problem would
manifest itself.
I've now changed the script to:
1. destroy snaphot (if it exists)
2. create snapshot
3. copy data
I've not seen the problem reoccur for four days, keeping my fingers
crossed.
I tried to replicate the situation in an VMware image, but so far have
been unsuccessful.
Stefan
--
Stefan Bethke <stb at lassitu.de> Fon +49 151 14070811
More information about the freebsd-current
mailing list