freebsd stable - May 2017 - zpool imported twice with different names (was Re: Fwd: ZFS)

> On May 16, 2017, at 10:26 AM, Eric A. Borisch <eborisch at gmail.com>
wrote:
> 
> On Tue, May 16, 2017 at 1:31 AM, Trond Endrest?l <
> Trond.Endrestol at fagskolen.gjovik.no> wrote:
> 
>> I guess you had a /boot/zfs/zpool.cache file referring to the original
>> zroot pool. Next, the kernel found the vega pool and didn't realise
>> these two pools are the very same.
>> 
> 
> Assuming this is the case, shouldn't it be fixed? A check while
importing
> that the guid of the pool targeted for import is not in the set of
> currently active guids would be worthwhile, but it -- apparently, if this
> is reproducible -- doesn't exist?
When you use the -f (force) flag all bets are off. The assumption is that you
_know_ it is safe to import the zpool as commanded. In this case, it was not.

Many sysadmins I know have gotten into the sloppy (in my opinion) habit of using
the force option (for various things) all the time. The force flag, whether it
be on a zpool import or a kill -9 should be the last resort when the non-forced
command fails.

On Tue, May 16, 2017 at 8:53 PM, Paul Kraus <paul at kraus-haus.org>
wrote:
>
>
> > On May 16, 2017, at 10:26 AM, Eric A. Borisch <eborisch at
gmail.com>
wrote:
> >
> > On Tue, May 16, 2017 at 1:31 AM, Trond Endrest?l <
> > Trond.Endrestol at fagskolen.gjovik.no> wrote:
> >
> >> I guess you had a /boot/zfs/zpool.cache file referring to the
original
> >> zroot pool. Next, the kernel found the vega pool and didn't
realise
> >> these two pools are the very same.
> >>
> >
> > Assuming this is the case, shouldn't it be fixed? A check while
importing
> > that the guid of the pool targeted for import is not in the set of
> > currently active guids would be worthwhile, but it -- apparently, if
this
> > is reproducible -- doesn't exist?
>
> When you use the -f (force) flag all bets are off. The assumption is that
you _know_ it is safe to import the zpool as commanded. In this case, it
was not.
>
> Many sysadmins I know have gotten into the sloppy (in my opinion) habit
of using the force option (for various things) all the time. The force
flag, whether it be on a zpool import or a kill -9 should be the last
resort when the non-forced command fails.


Short version:

It's not the -f causing the problem, it's the parsing and (double)
importing via /boot/zfs/zpool.cache that is.

Longer story:

I've been able to reproduce the issue, and if I delete the
/boot/zpool.cache file from the (alt rooted during live CD session) renamed
pool before rebooting into it, everything is fine.

So it is not the import with -f that is causing the problem here, it is the
following reboot when the zpool.cache file is parsed and ensuing
double-import. (As an aside, using the -f is required to import a pool last
used and not exported by another system, and is a common and documented use
case. If you look at the code, it turns on a the ZFS_IMPORT_ANY_HOST flag,
not an 'ignore all errors' state. There is a separate -F which is more
'force'-ish (turns on rewinding).)

This points to error checking while importing pools via the cache as one
immediate place to look, specifically to exclude processing of any GUIDs
already active on the system. A more general change to prevent importing
two pools with the same GUID is also worthwhile (IMHO) and would prevent it
the problem, too.

  - Eric