From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 15:47:23 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 BB700106564A for ; Thu, 26 Feb 2009 15:47:23 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C32F8FC1D for ; Thu, 26 Feb 2009 15:47:22 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [88.153.16.241] (helo=localhost) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LciSH-0002Jv-77 for freebsd-current@freebsd.org; Thu, 26 Feb 2009 16:47:21 +0100 Date: Thu, 26 Feb 2009 16:47:20 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20090226164720.390dbd14@fabiankeil.de> In-Reply-To: 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: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Df-Sender: 775067 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: Thu, 26 Feb 2009 15:47:24 -0000 Stefan Bethke wrote: > 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. Until I stopped doing it, I often got panics this way: 1) Build some port 2) Update the ports by rolling back the last snapshot to receive another one (zfs receive -vF) 3) Run mergemaster -a. Wait a few seconds. Dumping core doesn't work on that system (known problem) and as I usually did this from Xorg I couldn't get to the debugger either. Fabian