Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Oct 2012 23:59:04 +0300
From:      Nikolay Denev <ndenev@gmail.com>
To:        Fabian Keil <freebsd-listen@fabiankeil.de>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: zpool scrub on pool from geli devices offlines the pool?
Message-ID:  <EE2FEA99-1090-4479-8261-B2847D550CA8@gmail.com>
In-Reply-To: <20121004222422.68d176ec@fabiankeil.de>
References:  <5A5FE35F-7D68-4E83-A88D-3002B51F2E00@gmail.com> <20121004222422.68d176ec@fabiankeil.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On Oct 4, 2012, at 11:24 PM, Fabian Keil <freebsd-listen@fabiankeil.de> =
wrote:

> Nikolay Denev <ndenev@gmail.com> wrote:
>=20
>> 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 =
devices,
>> but this caused geli "detach on last close" to kick in=20
>> which resulted in offline pool from UNAVAILABLE devices.=20
>=20
> This is a known issue:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/117158
>=20
> The fact that the system didn't panic seems like an improvement,
> although this might be the result of the different pool layout.
>=20
>>  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 =
clear'.
>>   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 online,
>> but shows permanent metadata errors=85
>=20
> I'd expect the "permanent" metadata errors to be gone after
> the scrubbing is completed.
>=20
>> Any ideas why this happned from a simple zpool scrub, and how it can =
be prevented?
>> Just disable "detach on last close" for the geli devices?
>=20
> At least that was Pawel's recommendation in 2007:
> =
http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078107.htm=
l
>=20
> Fabian

Thanks for the information, I have missed that.

And yep, the pool reports as ONLINE without errors after the reboot.
I'll add geli_autodetach=3D"NO" to rc.conf.

Regards,
Nikolay




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE2FEA99-1090-4479-8261-B2847D550CA8>