From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 21:34:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ACC81065670 for ; Wed, 25 Feb 2009 21:34:07 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id ACBC38FC12 for ; Wed, 25 Feb 2009 21:34:06 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n1PLY4Iq074218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 Feb 2009 22:34:05 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: FreeBSD Current In-Reply-To: <7EFAB629-75C5-41C1-BDAC-ADE5F69D9EF6@lassitu.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 22:34:04 +0100 References: <76873DDF-D21B-48AF-9AFB-5A2747BE406B@lassitu.de> <3A302EE1-F54D-4415-BC13-CA8ABBA320EC@lassitu.de> <171C5946-63D1-4AC7-89F7-A951BEF3D1C6@lassitu.de> <7EFAB629-75C5-41C1-BDAC-ADE5F69D9EF6@lassitu.de> X-Mailer: Apple Mail (2.930.3) Subject: Re: zfs: using, then destroying a snapshot sometimes panics zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:34:08 -0000 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 Fon +49 151 14070811