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

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?

Again, assuming this is reproducible.

 - Eric

> 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 05/16/2017 04:26 PM, Eric A. Borisch 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?
> 
> Again, assuming this is reproducible.
> 
It is reproducible. Except for a check in ZFS, I would also expect
that the device cannot be opened twice for writing, that is,
protected by GEOM.

Nikos