Re: zfs: using, then destroying a snapshot sometimes panics zfs

From: Stefan Bethke <stb_at_lassitu.de>
Date: Wed, 25 Feb 2009 22:34:04 +0100
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
Received on Wed Feb 25 2009 - 20:34:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC