zpool scrub causes geli vdev to detach
Fabian Keil
freebsd-listen at fabiankeil.de
Fri Oct 12 11:14:01 PDT 2007
Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:
> On Thu, Oct 11, 2007 at 07:05:17PM +0200, Fabian Keil wrote:
> > this zpool:
> >
> > fk at TP51 ~ $sudo zpool status
> > pool: tank
> > state: ONLINE
> > scrub: scrub completed with 0 errors on Thu Oct 11 13:56:28 2007
> > config:
> >
> > NAME STATE READ WRITE CKSUM
> > tank ONLINE 0 0 0
> > ad0s3f.eli ONLINE 0 0 0
> > ad0s2.eli ONLINE 0 0 0
> >
> > errors: No known data errors
> >
> > worked without issues when it only consisted of ad0s3f.eli,
> > but then I added ad0s2.eli and now scrubbing the pool leads to:
> >
> > Unread portion of the kernel message buffer:
> > GEOM_ELI: Detached ad0s2.eli on last close.
> > GEOM_LABEL: Label for provider ad0s2 is msdosfs/?A.?,{(#0.
> > panic: Function g_eli_orphan_spoil_assert() called for ad0s3f.eli.
> > KDB: enter: panic
> > panic: from debugger
> > Uptime: 5m27s
> > Physical memory: 1014 MB
> > Dumping 120 MB: 105 89 73 57 41 25 9
> > Is there an obvious solution, or should I file a PR about this?
>
> Please file PR, but let me explain.
>
> GELI's detach-on-last-close mechanism is a general purpose mechanism, it
> may not work correctly with ZFS, because ZFS sometimes closes and reopen
> providers, which will make GELI to detach. In other words you shouldn't
> configure detach-on-last-close for ZFS components. It shouldn't panic
> still.
Thanks for the quick response, Pawel. I'll file the PR tomorrow.
Before coming up with the "workaround" I already spend some
time reading geli(8) looking for a disable-detach-on-last-close
option, but obviously didn't find it.
Turns out I unintentionally configured detach-on-last-close
through /etc/defaults/rc.conf. I just added geli_autodetach="NO"
to /etc/rc.conf and the problem is indeed gone.
Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071012/5edd883d/signature.pgp
More information about the freebsd-current
mailing list