From owner-freebsd-fs@FreeBSD.ORG  Fri Apr  6 17:21:34 2012
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 842991065670;
	Fri,  6 Apr 2012 17:21:34 +0000 (UTC)
	(envelope-from mckusick@mckusick.com)
Received: from chez.mckusick.com (unknown
	[IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452])
	by mx1.freebsd.org (Postfix) with ESMTP id 3E4D48FC18;
	Fri,  6 Apr 2012 17:21:34 +0000 (UTC)
Received: from chez.mckusick.com (localhost [127.0.0.1])
	by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q36HLTj6030692;
	Fri, 6 Apr 2012 10:21:29 -0700 (PDT)
	(envelope-from mckusick@chez.mckusick.com)
Message-Id: <201204061721.q36HLTj6030692@chez.mckusick.com>
To: "Desai, Kashyap" <Kashyap.Desai@lsi.com>
In-reply-to: <20120406130006.GC1336@garage.freebsd.pl> 
Date: Fri, 06 Apr 2012 10:21:29 -0700
From: Kirk McKusick <mckusick@mckusick.com>
X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY
	autolearn=failed version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com
Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>,
	"Kenneth D.Merry" <ken@freebsd.org>,
	Pawel Jakub Dawidek <pjd@freebsd.org>, "McConnell,
	Stephen" <Stephen.McConnell@lsi.com>
Subject: Re: Kernel crash at "softdep_deallocate_dependencies" 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 17:21:34 -0000

Following through on Pawel Jakub Dawidek's comments, there is no
way that the filesystem can recover when a large piece of its has
disappeared.  The panic that you are getting is because the soft
updates system realizes that allowing writes to continue on the
filesystem will cause it to be corrupted in an unrepairable way.
As it has no way to cleanly downgrade it to read-only or unmount
it, its only choice is to panic.

If you do not like this panic, you can disable soft updates using:

	tunefs -n disable <filesystem>

Absent the soft updates integrity checking, the filesystem will
carry on a good bit longer (though after a reboot it will likely
be unrecoverable even if you have put the disk back into it).

	Kirk McKusick