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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20171003/001f71dd/attachment.sig>