Re: panic: geli vs. zfs scrubbing

From: Pawel Jakub Dawidek <pjd_at_FreeBSD.org>
Date: Thu, 30 Aug 2007 21:38:58 +0200
On Thu, Aug 30, 2007 at 07:56:48PM +0200, Ulrich Spoerlein wrote:
> Hi -current,
> 
> I found a reproducible panic with GELI's 'detach on close' feature
> interfering with 'zpool scrub' of an eli provider.
> 
> root_at_roadrunner: ~# zpool status
>   pool: tank
>  state: ONLINE
>  scrub: scrub completed with 0 errors on Thu Aug 30 19:35:14 2007
> config:
> 
>         NAME          STATE     READ WRITE CKSUM
>         tank          ONLINE       0     0     0
>           ad0s4d.eli  ONLINE       0     0     0
> 
> Where /usr and /var are on tank (among others). This setup is working
> just fine (module buffer cache anomalies). Anyway, I issued a 'zpool
> scrub tank' just for kicks, here's the panic (hand transcribed):
> 
> # zpool scrub tank
> GEOM_ELI: Detached ad0s4d.eli on last close.
> panic: function g_eli_orphan_spoil_assert() called for ad0s4d.eli
> panic()
> g_eli_orphan_spoil_assert()
> g_spoil_event()
> g_run_events()
> g_event_procbody()

Yes, ZFS doesn't open providers and keep them open, it just opens them
as needed, so GELI detach-on-close feature is no good here.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Received on Thu Aug 30 2007 - 17:40:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC