From owner-freebsd-fs@freebsd.org Mon Jan 15 16:01:43 2018 Return-Path: Delivered-To: freebsd-fs@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 4070DEB6F21 for ; Mon, 15 Jan 2018 16:01:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0806C7E42C for ; Mon, 15 Jan 2018 16:01:42 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.47] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 42D049DD818; Mon, 15 Jan 2018 16:54:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Academic exercise: trying to recover a corrupted pool From: Borja Marcos In-Reply-To: Date: Mon, 15 Jan 2018 16:54:09 +0100 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1DB0315C-D267-4571-864F-73D1B275111B@sarenet.es> References: To: Borja Marcos X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 16:01:43 -0000 > On 8 Jan 2018, at 15:25, Borja Marcos wrote: >=20 >=20 > Hi, >=20 > ONLY AS AN ACADEMIC EXERCISE, WARNING :) >=20 > I have a broken ZFS pool and I=E2=80=99m wondering wether it should be = readable. The pool was made with four > apparently troublesome OCZ SSD drives pulled from other systems. They = are connected to a LSI2008 adapter. >=20 > The pool was created as a raidz2, so it=E2=80=99s supposed to survive = the loss of two drives. It has lost two of them > and I am unable to import it. >=20 > I have lost no useful data, I was using it just for testing. Now it = has become an interesting study subject though :) >=20 > Any ideas? I have tried to recover even doing the =E2=80=9Cradical = thing=E2=80=9D (zdb -Z -AAA -e -p /dev poolname). No success. Now this is interesting. I copied the two surviving drives to data files = on another system using =E2=80=9Cdd=E2=80=9D. And I used mdconfig to create file backed ram disks. mdconfig -a -f /pool/disk1 mdconfig -a -f /pool/disk2 Trying an import with zpool import -R /mnt -N -m -f -F -X poolname I got a panic. Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 02 fault virtual address =3D 0x188 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff81381901 stack pointer =3D 0x28:0xfffffe046bf2b250 frame pointer =3D 0x28:0xfffffe046bf2b270 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (zio_read_intr_6_0) trap number =3D 12 panic: page fault cpuid =3D 1 KDB: stack backtrace: #0 0xffffffff806e3c17 at kdb_backtrace+0x67 #1 0xffffffff806a0176 at vpanic+0x186 #2 0xffffffff8069ffe3 at panic+0x43 #3 0xffffffff809953bd at trap_fatal+0x34d #4 0xffffffff80995419 at trap_pfault+0x49 #5 0xffffffff80994c6a at trap+0x29a #6 0xffffffff80979bb1 at calltrap+0x8 #7 0xffffffff81380fba at vdev_queue_io_to_issue+0x23a #8 0xffffffff81380d33 at vdev_queue_io+0x103 #9 0xffffffff813a3bbc at zio_vdev_io_start+0x24c #10 0xffffffff813a05bc at zio_execute+0xac #11 0xffffffff8139ff0b at zio_nowait+0xcb #12 0xffffffff8138205c at vdev_raidz_io_start+0x48c #13 0xffffffff813a3c1d at zio_vdev_io_start+0x2ad #14 0xffffffff813a05bc at zio_execute+0xac #15 0xffffffff8139ff0b at zio_nowait+0xcb #16 0xffffffff813802f1 at vdev_mirror_io_done+0x1f1 #17 0xffffffff813a3f58 at zio_vdev_io_done+0x1c8 Uptime: 27d3h5m23s =20=