panic: geli vs. zfs scrubbing
Pawel Jakub Dawidek
pjd at FreeBSD.org
Thu Aug 30 12:40:35 PDT 2007
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070830/241c9b2e/attachment.pgp
More information about the freebsd-current
mailing list