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!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC