Date: Fri, 12 Oct 2007 20:13:52 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: zpool scrub causes geli vdev to detach Message-ID: <20071012201352.71f79aca@fabiankeil.de> In-Reply-To: <20071011173846.GB52831@garage.freebsd.pl> References: <20071011190517.770fd3ab@fabiankeil.de> <20071011173846.GB52831@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/R9BWCdB5WUJzppsVLyvFL13
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
> On Thu, Oct 11, 2007 at 07:05:17PM +0200, Fabian Keil wrote:
> > this zpool:
> >=20
> > fk@TP51 ~ $sudo zpool status
> > pool: tank
> > state: ONLINE
> > scrub: scrub completed with 0 errors on Thu Oct 11 13:56:28 2007
> > config:
> >=20
> > NAME STATE READ WRITE CKSUM
> > tank ONLINE 0 0 0
> > ad0s3f.eli ONLINE 0 0 0
> > ad0s2.eli ONLINE 0 0 0
> >=20
> > errors: No known data errors
> >=20
> > worked without issues when it only consisted of ad0s3f.eli,
> > but then I added ad0s2.eli and now scrubbing the pool leads to:
> >=20
> > Unread portion of the kernel message buffer:
> > GEOM_ELI: Detached ad0s2.eli on last close.
> > GEOM_LABEL: Label for provider ad0s2 is msdosfs/?A.?,{(#0.
> > panic: Function g_eli_orphan_spoil_assert() called for ad0s3f.eli.
> > KDB: enter: panic
> > panic: from debugger
> > Uptime: 5m27s
> > Physical memory: 1014 MB
> > Dumping 120 MB: 105 89 73 57 41 25 9
> > Is there an obvious solution, or should I file a PR about this?
>=20
> Please file PR, but let me explain.
>=20
> GELI's detach-on-last-close mechanism is a general purpose mechanism, it
> may not work correctly with ZFS, because ZFS sometimes closes and reopen
> providers, which will make GELI to detach. In other words you shouldn't
> configure detach-on-last-close for ZFS components. It shouldn't panic
> still.
Thanks for the quick response, Pawel. I'll file the PR tomorrow.
Before coming up with the "workaround" I already spend some
time reading geli(8) looking for a disable-detach-on-last-close
option, but obviously didn't find it.
Turns out I unintentionally configured detach-on-last-close
through /etc/defaults/rc.conf. I just added geli_autodetach=3D"NO"
to /etc/rc.conf and the problem is indeed gone.
Fabian
--Sig_/R9BWCdB5WUJzppsVLyvFL13
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHD7lgBYqIVf93VJ0RAhiVAKDHTig0o8qkYqisYA9srxnYedjT0wCdGcWU
+llzRgUVSAkPOT+zmf0CXis=
=he9o
-----END PGP SIGNATURE-----
--Sig_/R9BWCdB5WUJzppsVLyvFL13--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071012201352.71f79aca>