panic: geli vs. zfs scrubbing

From: Ulrich Spoerlein <uspoerlein_at_gmail.com>
Date: Thu, 30 Aug 2007 19:56:48 +0200
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()


The workaround is to set geli_autodetach=NO in /etc/rc.conf. After that,
scrubbing is doing its thing. Would be nice to have something like geli
detach -l, which turns *off* the close-on-detach flag for an already
attached provider. That way, you can use it as a one-shot workaround.


Cheers,
Ulrich Spoerlein
-- 
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
Received on Thu Aug 30 2007 - 15:57:09 UTC

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