From owner-freebsd-fs@FreeBSD.ORG Tue Feb 17 10:24:28 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55B49B4B for ; Tue, 17 Feb 2015 10:24:28 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 12FF8CE8 for ; Tue, 17 Feb 2015 10:24:26 +0000 (UTC) Received: from [78.35.133.36] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YNfKE-0000Xf-MQ for freebsd-fs@freebsd.org; Tue, 17 Feb 2015 11:24:18 +0100 Date: Tue, 17 Feb 2015 11:24:27 +0100 From: Fabian Keil To: freebsd-fs@freebsd.org Subject: Re: zfs set running_with_scissors=on zroot Message-ID: <20895a7f.19949a2f@fabiankeil.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:24:28 -0000 --Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Zaphod Beeblebrox wrote: > I've been struggling for awhile with zdb and friends recovering some data > from a curiously problematic old ZFS array and I had an idea: >=20 > Why not add a 'running_with_scissors' or maybe more properly named > 'read_what_you_got_anyways' flag to zfs. >=20 > Maybe this produces some garbage for a problem file or maybe it doesn't I > see two scenarios where this is useful: >=20 > 1) where ZFS has declared an "error" somewhere where a scrub will > eventually remove that error. >=20 > 2) where ZFS is having some sort of problem and the user just wants to try > pushing through it. >=20 > My concept of "how this would work" is that the flag would stop the > machinery that would normally stop the data from being delivered. I missed such a feature in the past as well, however I don't remember having seen this behaviour so far: > Note that case (1) might also be ameliorated by a flag or behavior that > rechecked only the blocks and checksums of data in question. Right now, = if > ZFS has "declared" something bad, it will return an error when you access > it --- even if a subsequent "scrub" would remove that flag --- that scrub > can take many, many hours. I'm using several pools where temporary read errors (USB disconnects etc.) resulted in "zpool status -v" showing files with "Permanent errors", however the files can be still read completely and the returned data is valid. While I sometimes see files with errors that can't be completely read anymore, I've seen no indication so far that the files actually aren't corrupted on disk. Usually this happens when writing to a pool whose vdevs get temporarily disconnected and reconnected without exporting the pool first. Fabian --Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTjFtgACgkQBYqIVf93VJ3oMwCglCBIkHRkLtKuVLCRCnXP7DTJ gMAAnAjlw05fvxxwuUVqsc9b5TlDI2kD =jOSP -----END PGP SIGNATURE----- --Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn--