Date: Tue, 17 Feb 2015 11:24:27 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-fs@freebsd.org Subject: Re: zfs set running_with_scissors=on zroot Message-ID: <20895a7f.19949a2f@fabiankeil.de> In-Reply-To: <CACpH0Mc_ndaeJgqgBmcZ4Dt-DEseTQ4Osq68M6G%2B7uiNE0_Pzg@mail.gmail.com> References: <CACpH0Mc_ndaeJgqgBmcZ4Dt-DEseTQ4Osq68M6G%2B7uiNE0_Pzg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/1Iw+zkUI/1cgO5TnoNeb8Sn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Zaphod Beeblebrox <zbeeble@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20895a7f.19949a2f>