From owner-freebsd-stable@freebsd.org Tue Apr 30 00:24:27 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91E2815A1C2B for ; Tue, 30 Apr 2019 00:24:27 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (hades.sorbs.net [72.12.213.40]) by mx1.freebsd.org (Postfix) with ESMTP id 352DA83F81; Tue, 30 Apr 2019 00:24:27 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [10.10.0.230] (gate.mhix.org [203.206.128.220]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0PQR005VI0FVZY40@hades.sorbs.net>; Mon, 29 Apr 2019 17:38:22 -0700 (PDT) Subject: Re: ZFS... From: Michelle Sullivan X-Mailer: iPad Mail (16A404) In-reply-to: <20190429171347.GV72200@home.opsec.eu> Date: Tue, 30 Apr 2019 10:24:22 +1000 Cc: freebsd-stable Content-transfer-encoding: quoted-printable Message-id: References: <30506b3d-64fb-b327-94ae-d9da522f3a48@sorbs.net> <20190429171347.GV72200@home.opsec.eu> To: Kurt Jaeger X-Rspamd-Queue-Id: 352DA83F81 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.93 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.93)[-0.930,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 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, 30 Apr 2019 00:24:27 -0000 Michelle Sullivan http://www.mhix.org/ Sent from my iPad > On 30 Apr 2019, at 03:13, Kurt Jaeger wrote: >=20 > Hi! >=20 >> I know I'm not going to be popular for this, but I'll just drop it here >> anyhow. >>=20 >> http://www.michellesullivan.org/blog/1726 >=20 > With all due respect, I think if that filesystem/server you describe > has not kept with all those mishaps, I think it's not perfect, but > nothing is. The killer was the catalog of errors, where you have resolver in progress, a= nd not one but two power failures...and just to let you know... one of the 6= kva upses caught fire the other no longer recognizes AC input... so it was n= ot your normal event. I had a good run with 8 years of running ZFS on this s= erver. >=20 >> Perhaps one should reconsider either: >>=20 >> 2. Defaulting to non ZFS filesystems on install. >=20 > I had more cases of UFS being toast than ZFS until now. I=E2=80=99ve toasted many, however I=E2=80=99ve always been able to get majo= rity(if not all) of the data. =20 >=20 >> 1. Looking at tools that may be able to recover corrupt ZFS metadata, or >=20 > Here I agree! Making tools available to dig around zombie zpools, > which is icky in itself, would be helpful! The one tool that I could think would be useful that is denied =E2=80=9Cbeca= use the data on disk is always right=E2=80=9D is not a fact for zfs, but a z= fs send with -AAA (like zdb) or a =E2=80=9Czfs walk=E2=80=9D tool that works= similar to zfs send but where you can tell it to ignore the checksum errors= (particularly in the structures of zfs rather than on the data itself) so y= ou can send what=E2=80=99s left of your data to another box either in part o= r fully. Particularly as in my case all the tools tell me all the data is th= ere and intact and it=E2=80=99s just the metadata that can=E2=80=99t be reco= vered/repaired. Regards, Michelle=