From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:05:10 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E21816A4CE for ; Fri, 27 Aug 2004 22:05:10 +0000 (GMT) Received: from pd2mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9996D43D53 for ; Fri, 27 Aug 2004 22:05:09 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd2mr5so.prod.shaw.ca (pd2mr5so-qfe3.prod.shaw.ca [10.0.141.8]) 2004))freebsd-stable@freebsd.org; Fri, 27 Aug 2004 13:56:58 -0600 (MDT) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd2mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I3400E9HFEYD400@pd2mr5so.prod.shaw.ca> for freebsd-stable@freebsd.org; Fri, 27 Aug 2004 13:56:58 -0600 (MDT) Received: from piii600.wadham.ox.ac.uk (S0106006067227a4a.vc.shawcable.net [24.87.233.42]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0I340041WFEWC0@l-daemon> for freebsd-stable@freebsd.org; Fri, 27 Aug 2004 13:56:58 -0600 (MDT) Date: Fri, 27 Aug 2004 12:55:39 -0700 From: Colin Percival In-reply-to: <20040827193605.GC28442@electra.cse.Buffalo.EDU> X-Sender: cperciva@popserver.sfu.ca (Unverified) To: Ken Smith Message-id: <6.1.0.6.1.20040827124846.03ac02d0@popserver.sfu.ca> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii References: <1076237332.20040827215245@kaluga.ru> <20040827193605.GC28442@electra.cse.Buffalo.EDU> cc: Pavel Merdine cc: freebsd-stable@freebsd.org Subject: Re: ffs_alloc panic patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 22:05:10 -0000 At 12:36 27/08/2004, Ken Smith wrote: > ... Here you again wind up in a > situation where the filesystem data structures on the disk can > become corrupted. Typically at some point the ffs code will > recognize that the metadata is incorrect and again a panic is > better than trying to carry on pretending nothing is wrong. Shouldn't a corrupt filesystem be handled by forcibly dismounting it, rather than invoking panic()? We certainly don't want to keep on using a corrupt filesystem, but we should attempt to isolate a single failing piece of hardware rather than allowing it to bring down the entire system. Colin Percival