Date: Tue, 26 Apr 2016 15:53:32 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-fs@freebsd.org Subject: Re: GELI + Zpool Scrub Results in GELI Device Destruction (and Later a Corrupt Pool) Message-ID: <20160426155332.3b7f277f@fabiankeil.de> In-Reply-To: <1461624665.22294.103.camel@michaeleichorn.com> References: <1461560445.22294.53.camel@michaeleichorn.com> <20160425101124.068c8333@fabiankeil.de> <1461587321.22294.85.camel@michaeleichorn.com> <20160425160625.5b585c8d@fabiankeil.de> <1461624665.22294.103.camel@michaeleichorn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/b=DucN3HhhVmotmLv_a5z=X Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Michael B. Eichorn" <ike@michaeleichorn.com> wrote: > On Mon, 2016-04-25 at 16:06 +0200, Fabian Keil wrote: > > "Michael B. Eichorn" <ike@michaeleichorn.com> wrote: > > =20 > > >=20 > > > On Mon, 2016-04-25 at 10:11 +0200, Fabian Keil wrote: =20 > > > > If yes, this is a known issue: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D117158 > > > > =C2=A0=C2=A0 =20 > > > Reading that bug in detail it appears to be *specifically* for the > > > kernel panic and that zfs closing and reopening providers is > > > expected > > > behavior, and that if geli has autodetach configured that it would > > > detach. > > >=20 > > > It stikes me that even though this is expected behavior it should > > > not > > > be. Is there a way we could prevent the detach when zfs does closes > > > and > > > reopens providers? I cannnot think of a case where the desired > > > behavior > > > is for the pool to detach when zfs wants to reopen it. =20 > > I suppose geli could delay the detachment a bit to give the consumer > > a chance to reopen it. =20 >=20 > That would probably work, but my inner engineer is dissatisfied with > the idea of slowing down all detachments to solve a single case. >=20 > What about a new feature whereby zfs (or any other consumer) can > inhibit the autodetach for a brief period? I don't really know if this > is feasible, but I thought I would ask. IIRC ZFS simply reopens the devices so nobody had to write code to read the label from an already opened device and update the internal state (and deal with the various locking issues). Changing this is feasible but someone would have to care enough to spend time on this. One could also work around the problem by letting ZFS open the already opened device read-only before reopening it with write access. That too is likely to dissatisfy your inner engineer. > Anything like this is probably too major to implement without some > thought and probably consensus building. So in the meantime I will file > my bug against the handbook to make sure geli_autodetach and zfs are > mentioned. The consensus seems to be that nobody cares enough about bugs like this one to work on fixing them. Fabian --Sig_/b=DucN3HhhVmotmLv_a5z=X Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlcfctwACgkQBYqIVf93VJ29CgCgo0hKqALtZEAvl+igImh7BUH4 7/EAn2Lo5ZP1tkyRGl/jGPm+Ogwyb8jm =zZ5w -----END PGP SIGNATURE----- --Sig_/b=DucN3HhhVmotmLv_a5z=X--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160426155332.3b7f277f>