Bezüglich Harry Schmalzbauer's Nachricht vom 02.10.2017 20:28 (localtime): > Bezüglich 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 really >>> 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 number 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 already > recreated pool). > > Unfortunately my knowledge about ZFS internals (transaction group number > relations to (ü)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 post..
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. The 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=on -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 – I thought... Thanks, -harry
signature.asc
Description: OpenPGP digital signature
