Date: Tue, 03 Oct 2017 10:43:12 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: panic: Solaris(panic): blkptr invalid CHECKSUM1 Message-ID: <59D34DA0.802@omnilan.de> In-Reply-To: <59D28550.3070700@omnilan.de> References: <59CFC6A6.6030600@omnilan.de> <59CFD37A.8080009@omnilan.de> <59D00EE5.7090701@omnilan.de> <493e3eec-53c6-3846-0386-d5d7f4756b11@FreeBSD.org> <59D28550.3070700@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9C6BC28EA8BA68787312F210 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 02.10.2017 20:28 (loca= ltime): > Bez=C3=BCglich Andriy Gapon's Nachricht vom 02.10.2017 13:49 (localtime= ): >> On 01/10/2017 00:38, Harry Schmalzbauer wrote: >>> Now my striped mirror has all 4 devices healthy available, but all >>> datasets seem to be lost. >>> No problem for 450G (99,9_%), but there's a 80M dataset which I'm rea= lly >>> missing :-( >> If it's not too late now, you may try to experiment with an "unwind" /= "extreme >> unwind" import using -F -n / -X -n. Or manually specifying a txg numb= er for >> import (in read-only mode). > Thanks for your reply! > > I had dumped one of each mirror's drive and attaching it as memory disk= > works as intended. > So "zfs import" offers me the corrupt backup (on the host with a alread= y > recreated pool). > > Unfortunately my knowledge about ZFS internals (transaction group numbe= r > relations to (=C3=BC)uberblocks) doesn't allow me to follow your hint. > > How can I determine the last txg#, resp. the ones before the last? > I guess 'zpool import -t' is the tool/parameter to use. > ZFS has wonderful documentation, but although this was a perfect reason= > to start learning the details about my beloved ZFS, I don't have the > time to. > > Is there a zdb(8) aequivalent of 'zpool import -t', so I can issue the > zdb check, wich doesn't crash the kernel but only zdb(8)? > > For regular 'zpool import', 'zdb -ce' seems to be such a synonym. At > least the crash report is identical, see my reply to Scott Bennett's po= st.. Made some progress. Unfortunately the zpool(8) man page doesn't mention some available options for the 'import' command. -T was the important one for me some days ago... Utilizing internet search engines would have discovered -T, but I haven't tried... This post describes the -T (-t for zdb) option very well: https://lists.freebsd.org/pipermail/freebsd-hackers/2013-July/043131.html= After attaching the dumps from two of the 4 drives as memory disk, 'zpool import' offers me: pool: cetusPsys id: 13207378952432032998 state: DEGRADED status: The pool was last accessed by another system. action: The pool can be imported despite missing or damaged devices. Th= e fault tolerance of the pool may be compromised if imported. see: http://illumos.org/msg/ZFS-8000-EY config: cetusPsys DEGRADED mirror-0 DEGRADED 8178308212021996317 UNAVAIL cannot open md3 ONLINE mirror-1 DEGRADED md2p5 ONLINE 4036286347185017167 UNAVAIL cannot open With 'zdb -lu /dev/md3' I picked a TXGid. The following doesn't panic the kernel: zpool import -o readonly=3Don -f -R /net -F -X -n -T 3757541 13207378952432032998 cetusPalt But: As soon as I don't tell test-run (not specifying -n), it fails with: cannot import 'cetusPsys': one or more devices is currently unavailable I'm clueless again :-( Is it impossible to import degraded pools in general, or only together with "-X -T"? Any tricks to convince zpool import to ignore the missing devices? I dumped only 2 of 4 disks, the physical disks are in usage. But people made me hope I have chances to recover data :-) Seems -T had really offered a way to do that, but I wasn't aware of it some days ago, so I only have these two tumps, but all data needed should be available =E2=80=93 I thought... Thanks, -harry --------------enig9C6BC28EA8BA68787312F210 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlnTTaYACgkQLDqVQ9VXb8jXbgCgicTp3/usBXZTEaeRZyWa2ESl uggAnj6GaTdZP/3/YDcUvjWFqQ/mP6eS =XZhw -----END PGP SIGNATURE----- --------------enig9C6BC28EA8BA68787312F210--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59D34DA0.802>