From owner-freebsd-fs@FreeBSD.ORG Fri Apr 6 19:40:55 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 5D5961065670; Fri, 6 Apr 2012 19:40:55 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 8937B8FC0C; Fri, 6 Apr 2012 19:40:54 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so651919wib.13 for ; Fri, 06 Apr 2012 12:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=5ajjgz2Hqd6JkZ/fsSlqKw2CJQvOI4mBUCHOXlwew+U=; b=GxbQ7K6ek5sewEuQnSXNtulT2LKhWApYuWd5KRmp9EEjB86831NCrcP9a0ZZXOKxXy 2F0/w4Zxk+yqC9VStC8W5mCdNpL49dZfmnP9QXjyQx1cYizxVrieYLpYY3/5iDPuBeLQ e+sbjElKW4medSCRnaRbRaq1gmCfRKX62GZcrcQqGAi6i6YlbNvxOSklnTw4J95MNy7x F5y1Vg+PdqjomPpF+EkZgAvJcXqf1ULUa1TrIwRx9DLG04c7q7EamNb8Gmwup03o/r4q H3qhAOdxTLF/IDDFos13BGQlHsBAx8CCouSASe5mM01MWYmszmVa1j7jET+uId314p+P guzQ== Received: by 10.180.103.134 with SMTP id fw6mr25377897wib.0.1333741253313; Fri, 06 Apr 2012 12:40:53 -0700 (PDT) Received: from strashydlo.local (gate19.robnet.pl. [194.105.132.219]) by mx.google.com with ESMTPS id e6sm9093710wix.8.2012.04.06.12.40.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Apr 2012 12:40:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 6 Apr 2012 21:40:48 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Kirk McKusick Message-ID: <20120406194047.GA1673@strashydlo.local> Mail-Followup-To: Kirk McKusick , "Desai, Kashyap" , "freebsd-fs@freebsd.org" , "Kenneth D.Merry" , Pawel Jakub Dawidek , "McConnell, Stephen" References: <20120406130006.GC1336@garage.freebsd.pl> <201204061721.q36HLTj6030692@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204061721.q36HLTj6030692@chez.mckusick.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" , Pawel Jakub Dawidek , "Kenneth D.Merry" , "Desai, Kashyap" , "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: Fri, 06 Apr 2012 19:40:55 -0000 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. 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. > 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). 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.