Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Oct 2012 22:24:22 +0200
From:      Fabian Keil <freebsd-listen@fabiankeil.de>
To:        freebsd-fs@freebsd.org
Subject:   Re: zpool scrub on pool from geli devices offlines the pool?
Message-ID:  <20121004222422.68d176ec@fabiankeil.de>
In-Reply-To: <5A5FE35F-7D68-4E83-A88D-3002B51F2E00@gmail.com>
References:  <5A5FE35F-7D68-4E83-A88D-3002B51F2E00@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/eLUGNlqK8CO8QdU4knNukxc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Nikolay Denev <ndenev@gmail.com> wrote:

> I have a zfs pool from 24 disks encrypted with geli.
>=20
> I just did a zpool scrub tank, and that probably reopened all of the devi=
ces,
> but this caused geli "detach on last close" to kick in=20
> which resulted in offline pool from UNAVAILABLE devices.=20

This is a known issue:
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/117158

The fact that the system didn't panic seems like an improvement,
although this might be the result of the different pool layout.

>   pool: tank
>  state: UNAVAIL
> status: One or more devices are faulted in response to IO failures.
> action: Make sure the affected devices are connected, then run 'zpool cle=
ar'.
>    see: http://illumos.org/msg/ZFS-8000-HC
>   scan: scrub in progress since Thu Oct  4 21:19:15 2012
>         1 scanned out of 8.29T at 1/s, (scan is slow, no estimated time)
>         0 repaired, 0.00% done
> config:
>=20
> 	NAME                      STATE     READ WRITE CKSUM
> 	tank                      UNAVAIL      0     0     0
[...]
>=20
> errors: 1 data errors, use '-v' for a list
>=20
> Dmesg shows :
>=20
> GEOM_ELI: Detached mfid1.eli on last close.
> =85
> GEOM_ELI: Detached mfid24.eli on last close.
>=20
> I then did /etc/rc.d/geli restart and zpool clear tank, and it is back on=
line,
> but shows permanent metadata errors=85

I'd expect the "permanent" metadata errors to be gone after
the scrubbing is completed.

> Any ideas why this happned from a simple zpool scrub, and how it can be p=
revented?
> Just disable "detach on last close" for the geli devices?

At least that was Pawel's recommendation in 2007:
http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078107.html

Fabian

--Sig_/eLUGNlqK8CO8QdU4knNukxc
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlBt8HkACgkQBYqIVf93VJ2o/gCggQ3hKU4zXUoA7D+K3HOwzqzv
tBoAn01iVH146hTIljOdnlDK216bfvKm
=mtka
-----END PGP SIGNATURE-----

--Sig_/eLUGNlqK8CO8QdU4knNukxc--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121004222422.68d176ec>