From owner-freebsd-stable@FreeBSD.ORG Tue Jul 1 18:47:55 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A25DDFD for ; Tue, 1 Jul 2014 18:47:55 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B121D2192 for ; Tue, 1 Jul 2014 18:47:54 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hi2so8375894wib.11 for ; Tue, 01 Jul 2014 11:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=XCPn//UXzzxqcCMQsUXafM8bH6290LzD7aUgMajuHXc=; b=CuEcx9tof0WNmVFFwSZDedEDP5d+MIdS339Tc/NrhrryaVxQ0p0xN7FGxNTil2RB/3 6u/axIKG41IF4jMsM/Tmf2irEPhVmt2kSZnF5G7OhfDCw/Vqu4MzibzVRTkLBCeFI11l +LBlRbyttoMLThlXhF1Hw31cWAObFuLezVv9xnUdFb06hrSkOtW2aoZyLn5OgU2GelSG PPGALGshxO7ogwgl9FvB6GxfKUVt/lneIw+x5jPmObX+kEK0d0cyBsUWw1MlK0GiOFDV Sy8wI5NKLmki04Bd7Dwjd98o8VckhJ0npTuBJUVv0MEZMEMFSXeVQkQlQG4h+UZEjD7U w02A== X-Received: by 10.181.13.5 with SMTP id eu5mr38920145wid.58.1404240472835; Tue, 01 Jul 2014 11:47:52 -0700 (PDT) Received: from brick.home (adfl225.neoplus.adsl.tpnet.pl. [79.184.115.225]) by mx.google.com with ESMTPSA id w9sm21531779wif.12.2014.07.01.11.47.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 11:47:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 1 Jul 2014 20:47:49 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Dmitry Sivachenko Subject: Re: 10/stable panic: softdep_deallocate_dependencies: dangling deps Message-ID: <20140701184749.GA8617@brick.home> Mail-Followup-To: Dmitry Sivachenko , Ronald Klop , freebsd-stable@freebsd.org References: <021AFCAD-7B0B-47FB-AAFF-8F7085C7E1A6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:47:55 -0000 On 0701T1457, Dmitry Sivachenko wrote: > > On 01 июля 2014 г., at 11:57, Ronald Klop wrote: > > > On Mon, 30 Jun 2014 14:22:02 +0200, Dmitry Sivachenko wrote: > > > >> Hello! > >> > >> I have several machines with rather fresh FreeBSD-10/stable. > >> > >> They all have 4 SATA drives, I have small gmirrored root+var and the rest of the drive space is mounted as /disk1, /disk2, etc (UFS2+SU). > >> When a single disk fails, system panics with "softdep_deallocate_dependencies: dangling deps" message: > >> http://people.freebsd.org/~demon/softdep.png > >> > >> Since all vital data (root+var) are mirrored, I expect OS to stay alive. > > > > Hi, > > > > So /disk1, /disk2 are not (g)mirrored? In that case the system cannot handle write failure. Because writes are not synchronous (for speed) there is no possibility to return an error to the application. > > > No, they are not (g)mirrored. > I expect read/write errors, but not kernel panic. Actually I encountered disk I/O errors since 2.2.5 and it is first time I faced kernel panic. Soft updates cannot gracefully handle IO errors. It _will_ panic. You can either prevent errors from happening by using redundancy (ie. mirroring), or disable soft updates. That's how it works, sorry. In theory it would be possible to prevent this from happening; panic here is actually to terminate the system before it corrupts data, and in situations like this one, where the disk is no longer accessible, it's not possible to corrupt anything. IIRC I've actually added a workaround for that a while ago, but, as you can see, it's not enough, and I don't understand soft updates well enough to fix it properly.