From owner-freebsd-fs@freebsd.org Tue Apr 26 15:10:19 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B43DB1CD71 for ; Tue, 26 Apr 2016 15:10:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 1F5AE18DA for ; Tue, 26 Apr 2016 15:10:18 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.159.183] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1av3WK-0001n9-TA for freebsd-fs@freebsd.org; Tue, 26 Apr 2016 15:59:21 +0200 Date: Tue, 26 Apr 2016 15:53:32 +0200 From: Fabian Keil 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/b=DucN3HhhVmotmLv_a5z=X"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 15:10:19 -0000 --Sig_/b=DucN3HhhVmotmLv_a5z=X Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Michael B. Eichorn" wrote: > On Mon, 2016-04-25 at 16:06 +0200, Fabian Keil wrote: > > "Michael B. Eichorn" 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--