Re: panic: geli vs. zfs scrubbing
- From: Pawel Jakub Dawidek <pjd@xxxxxxxxxxx>
- 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@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@xxxxxxxxxxx http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
Attachment:
pgpaBj4W3FKS9.pgp
Description: PGP signature
- References:
- panic: geli vs. zfs scrubbing
- From: Ulrich Spoerlein
- panic: geli vs. zfs scrubbing
- Prev by Date: Re: Another ZFS kernel panic on same block on every drive in raidz
- Next by Date: Re: Another ZFS kernel panic on same block on every drive in raidz
- Previous by thread: panic: geli vs. zfs scrubbing
- Next by thread: Multiple aliases with dhclient
- Index(es):