From owner-freebsd-fs@freebsd.org Wed May 17 21:12:16 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6508BD7138B; Wed, 17 May 2017 21:12:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E915650; Wed, 17 May 2017 21:12:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x22e.google.com with SMTP id q125so12600787pgq.2; Wed, 17 May 2017 14:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OWTKa7DOCMNQJXoDaOTRCgp716stR6ne//pxm3BAUiA=; b=G7S/54A309lIuMENoOMrz0KsHgt8SqGTDN3M1VDj1c4Ywq2QekJ1pOiGa+qdigrckV qw6QQt1NSpGPnVmW/RHqr1Qrf8xCJJpWXe9XPhc2HRiLzCrV5OdHKmdE/cPabW9NQnUB 9uAWgw6ba5NWc7G4VKHG+et7udGfrJu2FZbqD6x9Gvnu9siLx8FveBUbd24dk4FevNXe uSbGg2YSs5EN9Eb/fj08CEDEPHo2bQMk3g8oUNAhghr2cxp0OxmfNp0lXPHMwTSMNJ92 ToSKka6NLtr1I2/no8F1MvtngzV/t3JJ3DRuaftl+OGrKHZxBYQ57QHENPYAO6LgveKG CHnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OWTKa7DOCMNQJXoDaOTRCgp716stR6ne//pxm3BAUiA=; b=AzoSwkG9GW8bzqQ6g/TmwUGA3u9APPK7mwtoHAXgq+uCQ54crMDpVut8hlZH9IZBVZ q+SjlZVaUPDgYgP8XSDgvwzRj4z+V9mDeMs0QIcVxHvTQKBovrJdCcqaBJWcBhlAOAtn Dph42AUMfvi7TmPFKgcxXg+GiXcCC1OE621t5gZERuVISamjFm0Y3LBoP81Yd6fOM2PS zMe0bbsqt+BaQXKhzvVr777RtrSEaqhvLtrrfERCR0vE5RXMn7D+ugYdIXRGznar3G3v rElFnZfbBGBx7IhOfZkNDyO41l5NH6lCsBtLMCssOZ3uyKLA7rxz0kdUlPGLlCk+4FKA 5PKw== X-Gm-Message-State: AODbwcDR/0GsB70j993C19Z5EtgV/lVq/4kmP/0Yf5pDCBBA2cwVDiEJ Xz170B7Jc+PwftO6zqEvgm5VNDHGWA== X-Received: by 10.98.21.17 with SMTP id 17mr776347pfv.71.1495055535672; Wed, 17 May 2017 14:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Wed, 17 May 2017 14:12:15 -0700 (PDT) In-Reply-To: <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> From: "Eric A. Borisch" Date: Wed, 17 May 2017 16:12:15 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: "freebsd-fs@freebsd.org" , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 21:12:16 -0000 On Tue, May 16, 2017 at 8:53 PM, Paul Kraus wrote: > > > > On May 16, 2017, at 10:26 AM, Eric A. Borisch wrote: > > > > On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < > > Trond.Endrestol@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