From owner-freebsd-current@FreeBSD.ORG Tue Aug 13 12:23:36 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 82C4BDD1; Tue, 13 Aug 2013 12:23:36 +0000 (UTC) (envelope-from chris.torek@gmail.com) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3066A227C; Tue, 13 Aug 2013 12:23:36 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id pa12so6589220veb.2 for ; Tue, 13 Aug 2013 05:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EOCxlnqg2jeaGTkGe3ARjnGwSE4QF8fGRh8onEXsvmo=; b=UmoP2mWRoTXBpGecPZrVaGfeKG1iyt//+NnIEMWIaS1Wn+/j2JHIS9L/zruPV6zmIP An8DRMhpetIuKfCmXGiF4ma0D/M2Ui+G9NxD4lZysgDej8MNyvpcszz22FFwf354DyMR cIxCuAwSP2iMiKMkuEkliizGqvBZFHMnwNf0W6fFhq6hBTwGXq8TWShKqtTuG4dEcEmL /SPI0Dwo35I+6Lh+WyW6SnXXnKReWkLORwFw/A2Owj0kPxO21FMt/k4guqmmom3+cDoC 4TItD86rhumXMIAJOtDhu7bGiJgnMyf06ucrDIjt2xqNRBCJeQJaZplxDCqGz3WibijY AODg== MIME-Version: 1.0 X-Received: by 10.52.23.80 with SMTP id k16mr70541vdf.58.1376396614572; Tue, 13 Aug 2013 05:23:34 -0700 (PDT) Received: by 10.220.151.78 with HTTP; Tue, 13 Aug 2013 05:23:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 06:23:34 -0600 Message-ID: Subject: Re: Panic - ffs_valloc: dup alloc From: Chris Torek To: Adrian Chadd X-Mailman-Approved-At: Tue, 13 Aug 2013 12:43:32 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: AN , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:23:36 -0000 For what (little :-) ) it's worth, I got bit by this too. Ultimately it boils down to the problem that once the on-disk file system is sufficiently broken, the journal doesn't have enough information for fsck to even detect the problem, much less fix it. (In my case the problem most likely was created by a bad bit in RAM. That particular hardware has no ECC.) It seems to me that certain UFS panics (including "dup alloc", which was the one getting me too if I remember right) should poison the journal to force a full fsck. This won't necessarily solve everything, but it would at least carry the problem detection forward from the kernel into fsck... Chris