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