From owner-freebsd-stable@FreeBSD.ORG Sun Jan 15 12:08:15 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 BBB26106566C for ; Sun, 15 Jan 2012 12:08:15 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 36EC38FC12 for ; Sun, 15 Jan 2012 12:08:14 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-104-78.lns20.adl6.internode.on.net [121.45.104.78]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id q0FBvOn4068374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Jan 2012 22:27:30 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <3BCC7D95-F0BC-447D-9828-DD5B6A07A54A@lassitu.de> Date: Sun, 15 Jan 2012 22:27:23 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <2D076869-AE11-4205-9FAA-9BEACC8F9720@gsoft.com.au> References: <3BCC7D95-F0BC-447D-9828-DD5B6A07A54A@lassitu.de> To: Stefan Bethke X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, Joe Holden Subject: Re: UFS corruption panic 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: Sun, 15 Jan 2012 12:08:15 -0000 On 15/01/2012, at 18:42, Stefan Bethke wrote: > Most filesystems work under the assumption that they're the sole owner = of the disk. This means that any changes to the on-disk data must come = from filesystem code itself; if that data is inconstistent, it must be a = bug in the filesystem code. At this point, panic is the only course of = action to avoid even greater damage to the data. >=20 > In other words: don't do that then :-) OP didn't do anything silly, it really is a bug from the user POV. =46rom the kernel programmer POV it might not be, and certainly wasn't. = Times change though, every disk media is hot swappable these days, and = in any case assumptions change. That said, changing all those code paths which panic because of = corruption to instead re-mount read only (or similar) is a decidedly non = trivial task :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C