From owner-freebsd-current@FreeBSD.ORG Fri Dec 11 03:18:09 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 638A31065676 for ; Fri, 11 Dec 2009 03:18:09 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id CD4688FC1A for ; Fri, 11 Dec 2009 03:18:08 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-127-244.shv.bellsouth.net [98.67.127.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id A99B89996452; Thu, 10 Dec 2009 21:18:03 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id nBB3He8T085658; Thu, 10 Dec 2009 21:17:43 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Thu, 10 Dec 2009 21:17:39 -0600 (CST) From: Wes Morgan To: Jeremie Le Hen In-Reply-To: <20091210072147.GA4963@felucia.tataz.chchile.org> Message-ID: References: <20091210072147.GA4963@felucia.tataz.chchile.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.2 at warped X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Panic while doing zfs rename 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: Fri, 11 Dec 2009 03:18:09 -0000 On Thu, 10 Dec 2009, Jeremie Le Hen wrote: > Hi list, > > First, excuse me to post on -current@ while this problem happened with > -STABLE but RELENG_8 is still relatively close to HEAD and I have the > feeling that -stable@ is more concerned with configuration and maybe > userland problems. > > I've done the following command sequence on a fresh RELENG_8 from around > 3rd dec: > zfs send -R data/repos | zfs receive -d data/crepos > zfs destroy data/repos > zfs rename data/crepos/repos data/repos > > And this led to the following panic on rename: > > % Fatal trap 12: page fault while in kernel mode > % cpuid = 0; apic id = 00 > % fault virtual address = 0x780fe2a0 > % fault code = supervisor read, page not present > % instruction pointer = 0x20:0x806d1687 > % stack pointer = 0x28:0xcb41c750 > % frame pointer = 0x28:0xcb41c784 > % code segment = base 0x0, limit 0xfffff, type 0x1b > % = DPL 0, pres 1, def32 1, gran 1 > % processor eflags = resume, IOPL = 0 > % current process = 72605 (zfs) > % [thread pid 72605 tid 100435 ] > % Stopped at _sx_xlock_hard+0x21e: movl 0x1a0(%eax),%eax > % db> bt > % Tracing pid 72605 tid 100435 td 0x88b6c480 > % _sx_xlock_hard(8f2460a0,88b6c480,0,85ce8fc8,a1,...) at _sx_xlock_hard+0x21e > % _sx_xlock(8f2460a0,0,85ce8fc8,a1,866b2a70,...) at _sx_xlock+0x48 > % rrw_enter(8f2460a0,1,85cdf7b1,0,cb41c7e8,...) at rrw_enter+0x35 > % zfs_statfs(866b2a10,866b2a70,1d8,cb41c844,865a3a10,...) at zfs_statfs+0x39 > % __vfs_statfs(866b2a10,cb41c844,0,0,0,...) at __vfs_statfs+0x1f > % nullfs_statfs(865a3a10,865a3a70,806bd68b,865a3a70,865a3a10,...) at nullfs_statfs+0x46 > % __vfs_statfs(865a3a10,865a3a70,1d8,a5889340,cb41cb78,...) at __vfs_statfs+0x1f > % kern_getfsstat(88b6c480,cb41ccf8,8df8,0,1,...) at kern_getfsstat+0x2d0 > % getfsstat(88b6c480,cb41ccf8,c,cb41ccb0,8096d28a,...) at getfsstat+0x2e > % syscall(cb41cd38) at syscall+0x320 > % Xint0x80_syscall() at Xint0x80_syscall+0x20 > % --- syscall (395, FreeBSD ELF32, getfsstat), eip = 0x281742d7, esp = 0x7fbfc8dc, ebp = 0x7fbfc908 --- > > > FYI, after the crash, I could rename the filesystem without any problem. I think I saw this same panic last weekend after I migrated from an old raidz2 to a new larger volume. I didn't have the kernel set up to get a backtrace, so this is just a "me too", but it happened at exactly noon, which is when freebsd-snapshot would be creating and renaming snapshots. Just as you mentioned, after rebooting I was able to rename and destroy the snapshots without a problem. As extra data points, if any of it matters: - I do not have nullfs in my kernel. - Both the old and new pool are raidz2 - Both are attached to an mfi bus - the old pool had been exported and all of the devices detached - the new pool was been imported and renamed to the name of the old pool