Date: Mon, 25 Apr 2016 16:06:25 +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: <20160425160625.5b585c8d@fabiankeil.de> In-Reply-To: <1461587321.22294.85.camel@michaeleichorn.com> References: <1461560445.22294.53.camel@michaeleichorn.com> <20160425101124.068c8333@fabiankeil.de> <1461587321.22294.85.camel@michaeleichorn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] "Michael B. Eichorn" <ike@michaeleichorn.com> wrote: > On Mon, 2016-04-25 at 10:11 +0200, Fabian Keil wrote: > > "Michael B. Eichorn" <ike@michaeleichorn.com> wrote: > > > > > > > > I just ran into something rather unexpected. I have a pool > > > consisting > > > of a mirrored pair of geli encrypted partitions on WD Red 3TB > > > disks. > > > > > > The machine is running 10.3-RELEASE, the root zpool was setup with > > > GELI > > > encryption from the installer, the pool that is acting up was setup > > > per > > > the handbook. > > [...] > > > > > > I had just noticed that I had failed to enable the zpool scrub > > > periodic > > > on this machine. So I began to run zpool scrub by hand. It > > > succeeded > > > for the root pool which is also geli encrypted, but when I ran it > > > against my primary data pool I encountered: > > > > > > Apr 24 23:18:23 terra kernel: GEOM_ELI: Device ada3p1.eli > > > destroyed. > > > Apr 24 23:18:23 terra kernel: GEOM_ELI: Detached ada3p1.eli on last > > > close. > > > Apr 24 23:18:23 terra kernel: GEOM_ELI: Device ada2p1.eli > > > destroyed. > > > Apr 24 23:18:23 terra kernel: GEOM_ELI: Detached ada2p1.eli on last > > > close. > > Did you attach the devices using geli's -d (auto-detach) flag? > > I am using whatever the default setup comes out of the rc.d scripts. > My rc.conf was: > > geli_devices="ada2p1 ada3p1" > geli_default_flags="-k /root/encryption.key" > zfs_enable="YES" > > I will try adding geli_autodetach="NO" and scubbing in about 9 hours. On FreeBSD the default (set in /etc/defaults/rc.conf) is YES. > > If yes, this is a known issue: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117158 > > > > 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. > > 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. I suppose geli could delay the detachment a bit to give the consumer a chance to reopen it. Fabian [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEUEARECAAYFAlceJGEACgkQBYqIVf93VJ0dIACgto8ufhTsp8yx2efZjeN5a0ze 3u0AmPLxV2QspWG57OTC1ADtc9/YZ0U= =7XHt -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160425160625.5b585c8d>