From owner-freebsd-stable@freebsd.org Tue Oct 3 14:19:55 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FEE0E3E26A for ; Tue, 3 Oct 2017 14:19:55 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EB8275E97; Tue, 3 Oct 2017 14:19:55 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v93EJrtp099859; Tue, 3 Oct 2017 16:19:53 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2677E265; Tue, 3 Oct 2017 16:19:53 +0200 (CEST) Message-ID: <59D39C88.4040501@omnilan.de> Date: Tue, 03 Oct 2017 16:19:52 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon CC: freebsd-stable@FreeBSD.org Subject: Re: panic: Solaris(panic): blkptr invalid CHECKSUM1 References: <59CFC6A6.6030600@omnilan.de> <59CFD37A.8080009@omnilan.de> <59D00EE5.7090701@omnilan.de> <493e3eec-53c6-3846-0386-d5d7f4756b11@FreeBSD.org> <59D28550.3070700@omnilan.de> <59D34DA0.802@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 03 Oct 2017 16:19:53 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 03 Oct 2017 14:19:55 -0000 Bezüglich Andriy Gapon's Nachricht vom 03.10.2017 11:20 (localtime): > On 03/10/2017 11:43, Harald Schmalzbauer wrote: > ... >> action: The pool can be imported despite missing or damaged devices. The >> fault tolerance of the pool may be compromised if imported. > ... >> Is it impossible to import degraded pools in general, or only together> with "-X -T"? > It should be possible to import degraded pools... > Perhaps the pool originally had more devices? Like log devices. > Or maybe there is some issue with the txg you picked. > > By the way, I think that you didn't have to provide -T option for -F or -X. > It's either -F or -X or -T , the first two try to figure out txg > automatically. But I could be wrong. You're right that -T works without F[X] flag, but -X needs -F. Unfortunately not specifying a distinct txg leads to panic. Specifying one leads to "device is missing". Which is true, but only redundant data... It's abosultely sure that this pool never had any log or cache or other device than the two mirror vdevs. zdb -l confirms that. Have tried several different txg IDs, but the latest 5 or so lead to the panic and some other random picked all claim missing devices... Doh, if I only knew about -T some days ago, when I had all 4 devices available. I haven't expected problems due to missing redundant mirrors. Can anybody imagine why degraded import doesn't work in my case and how to work arround? Will try to provide the sparse zdb dumps in addition, maybe that changes anything. But I'm sure these don't have much data., dump time was within 3 seconds at most. Thanks, -harry