From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 06:22:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4290F106566B; Mon, 9 Apr 2012 06:22:35 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE778FC08; Mon, 9 Apr 2012 06:22:34 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT4KAJEpfMiU2CdpExOIQt+JzhEGJb7+t@postini.com; Sun, 08 Apr 2012 23:22:34 PDT Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 9 Apr 2012 02:27:34 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 9 Apr 2012 02:22:27 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 9 Apr 2012 11:52:24 +0530 From: "Desai, Kashyap" To: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= , "Kirk McKusick" Date: Mon, 9 Apr 2012 11:52:22 +0530 Thread-Topic: Kernel crash at "softdep_deallocate_dependencies" Thread-Index: Ac0ULTFrKrXpfHM7RceBRgQ+7I27bQB684OQ Message-ID: References: <20120406130006.GC1336@garage.freebsd.pl> <201204061721.q36HLTj6030692@chez.mckusick.com> <20120406194047.GA1673@strashydlo.local> In-Reply-To: <20120406194047.GA1673@strashydlo.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" , Pawel Jakub Dawidek , "Kenneth D.Merry" , "McConnell, Stephen" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 06:22:35 -0000 Thanks for such wonderful technical discussion. Things are now clear and w= e are planning to do some experiment based on your feedback. ~ Kashyap > -----Original Message----- > From: Edward Tomasz Napiera=B3a [mailto:etnapierala@googlemail.com] On > Behalf Of Edward Tomasz Napierala > Sent: Saturday, April 07, 2012 1:11 AM > To: Kirk McKusick > Cc: Desai, Kashyap; freebsd-fs@freebsd.org; Kenneth D.Merry; Pawel Jakub > Dawidek; McConnell, Stephen > Subject: Re: Kernel crash at "softdep_deallocate_dependencies" >=20 > On Fri, Apr 06, 2012 at 10:21:29AM -0700, Kirk McKusick wrote: > > 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. >=20 > Actually, there is a third way, which is what UFS mounted without > softupdates does: do nothing. This works, because when ENXIO gets > returned, the device is already gone. >=20 > > If you do not like this panic, you can disable soft updates using: > > > > tunefs -n disable > > > > 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). >=20 > Apart of a situation where ENXIO would be returned, but the device > would stay accessible, which doesn't happen, afaik, what will actually > happen is that all the operations on a filesystem will return ENXIO, > except for reads for which the data is still in cache. Nothing will > get written, so no further damage will be done, and it will be possible > to forcibly unmount the filesystem without panicing.