Re: zpool scrub causes geli vdev to detach

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