From owner-freebsd-stable@FreeBSD.ORG Mon Jan 30 12:06:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D196106567C for ; Mon, 30 Jan 2012 12:06:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id ADE768FC08 for ; Mon, 30 Jan 2012 12:06:45 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id To5C1i00227AodY55o6l2L; Mon, 30 Jan 2012 12:06:45 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id To6k1i01P1t3BNj3fo6laG; Mon, 30 Jan 2012 12:06:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9590F102C1E; Mon, 30 Jan 2012 04:06:43 -0800 (PST) Date: Mon, 30 Jan 2012 04:06:43 -0800 From: Jeremy Chadwick To: Adam Strohl Message-ID: <20120130120643.GA46785@icarus.home.lan> References: <4F267B14.4060200@ateamsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F267B14.4060200@ateamsystems.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-Stable ML Subject: Re: FreeBSD 9 crash/deadlock when dump(8)ing file system with journaling enabled. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 12:06:46 -0000 On Mon, Jan 30, 2012 at 06:12:20PM +0700, Adam Strohl wrote: > A few days ago I discovered that running dump(8) on a file system > which has journaled soft updates enabled causes the machine to > become unresponsive. This is using FreeBSD 9.0-R. I can still > interact with the system a little bit (typing echos back) but never > get a response to any action. It seems like there is an I/O issue > (deadlock or overload) and CPU usage spikes as well. Resetting the > machine seems to be the only solution once this occurs (CTRL-C, > CTRL-ALT-DEL, logging in again, etc all fail). > > Disclaimer: I have only tested this as a VM under ESXi 5.0 as I > don't have access to any physical servers with 9.0 on them that I > can test with (I will soon though). > > As a side note this is the same issue reported here: > http://forums.freebsd.org/showthread.php?t=25787 > > For now I've turned off journaling (soft updates seem fine) and that > works around the issue. > > Let me know if I can provide more details etc! I'm not sure, but this may be an after-effect of known problems right now with SU+J on 9.0. It would help if you could state if you're using "dump -L" or not. I've seen the "deadlock" behaviour you describe on older FreeBSD versions (dating back to at least 7.x) when using "dump -L", which generates a fs snapshot. Obviously 7.x does not have SU+J, so I'm a little surprised disabling journalling fixes the problem for you. This type of problem is exactly why we have avoided use of filesystem snapshots on our systems for years upon years and why we use rsnapshot/rsync instead of dump. I'm sure if you Google you can find old posts from me talking about the problem. You may also be interested in the thread on freebsd-fs titled "kernel: panic: softdep_sync_buf: Unknown type jnewblk". I realise that's a panic vs. the deadlock you're seeing. You will need to search the mailing list for that subject, since not everyone's mail clients support Reference headers thus replies are scattered all over: http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/thread.html The most important thing to note is probably this: http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013573.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |