From owner-freebsd-stable@FreeBSD.ORG Sun Jan 15 08:12:08 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 42A7E106566B for ; Sun, 15 Jan 2012 08:12:08 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 041028FC08 for ; Sun, 15 Jan 2012 08:12:08 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 3DA1383982; Sun, 15 Jan 2012 08:12:06 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Sun, 15 Jan 2012 09:12:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3BCC7D95-F0BC-447D-9828-DD5B6A07A54A@lassitu.de> References: To: Joe Holden X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-stable@freebsd.org 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 08:12:08 -0000 Am 15.01.2012 um 05:20 schrieb Joe Holden: > Guys.... >=20 > Is a panic **really** appropriate for a filesystem that isn't even in > fstab? >=20 > ie; > panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry >=20 > Which happened to be an file-backed md volume that got changed as I = forgot > to unmount it beforehand, however as a result there is now = inconsistencies > and probably data corruption or even missing data on other important > filesystems (ie; /, /var etc) because there wasn't even a sync or any = kind > of other sensible behaviour. Yes, a panic is the correct action here. While I agree that it's super = annoying, the filesystem notices that something is *really* wrong. = Instead of letting the problem fester and continue to corrupt data, it = stops the system. 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. In other words: don't do that then :-) Stefan --=20 Stefan Bethke Fon +49 151 14070811