Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Mar 2009 23:51:10 -0400
From:      Yoshihiro Ota <ota@j.email.ne.jp>
To:        Guido van Rooij <guido@gvr.org>, Fabian Keil <freebsd-listen@fabiankeil.de>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, phk@freebsd.org
Subject:   Re: svn commit: r189625 - head/sys/geom/eli
Message-ID:  <20090310235110.c0c6f71e.ota@j.email.ne.jp>
In-Reply-To: <20090310180157.GA4663@gvr.gvr.org>
References:  <200903101523.n2AFNhs1065867@svn.freebsd.org> <20090310171948.1ac51696@fabiankeil.de> <20090310180157.GA4663@gvr.gvr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Mar 2009 19:01:57 +0100
Guido van Rooij <guido@gvr.org> wrote:

> On Tue, Mar 10, 2009 at 05:19:48PM +0100, Fabian Keil wrote:
> > > Log:
> > >   When attaching a geli on boot make sure that it is detached
> > >   upon last close. (needed for a gmirror to properly shutdown
> > >   upon reboot when a geli is on top the gmirror)
> > > 
> > 
> > Detach-on-last-close is known to cause panics when
> > scrubbing at least some ZFS pools:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117158
> > 
> > Quoting the PR:
> > |Quoting Pawel Jakub Dawidek's response to my initial report:
> > ||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. 
> > 
> 
> Grr. So we should make it tuneable. How about being able to set
> this flag with the geli command, like the G_ELI_FLAG_BOOT flag.
> 
> -Guido

Can we move its implementation into the GEOM framwork such that all of
GEOM classes can have detach-on-last-close?  It will need some kind of
custom hook such that each class can do something extra, i.e. gjournal
sync.  I often need to stop providers to securely detach USB disks.

Hiro



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090310235110.c0c6f71e.ota>