From owner-freebsd-questions@FreeBSD.ORG  Wed Nov  5 14:40:58 2014
Return-Path: <owner-freebsd-questions@FreeBSD.ORG>
Delivered-To: freebsd-questions@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id D70C03F5
 for <freebsd-questions@freebsd.org>; Wed,  5 Nov 2014 14:40:58 +0000 (UTC)
Received: from blue.qeng-ho.org (blue.qeng-ho.org [217.155.128.241])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 528623CE
 for <freebsd-questions@freebsd.org>; Wed,  5 Nov 2014 14:40:57 +0000 (UTC)
Received: from arthur.home.qeng-ho.org (arthur.home.qeng-ho.org [172.23.1.2])
 by fileserver.home.qeng-ho.org (8.14.7/8.14.5) with ESMTP id
 sA5EdhK8001848; Wed, 5 Nov 2014 14:39:44 GMT
 (envelope-from freebsd@qeng-ho.org)
Message-ID: <545A36AF.9030204@qeng-ho.org>
Date: Wed, 05 Nov 2014 14:39:43 +0000
From: Arthur Chance <freebsd@qeng-ho.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?UTF-8?B?VHJvbmQgRW5kcmVzdMO4bA==?= <Trond.Endrestol@fagskolen.gjovik.no>
Subject: Re: zpool component names - gpt vs. gptid
References: <5459E89F.7080801@qeng-ho.org>
 <alpine.BSF.2.11.1411051026360.1376@mail.fig.ol.no>
 <545A0067.1090005@qeng-ho.org>
 <alpine.BSF.2.11.1411051159030.1380@mail.fig.ol.no>
In-Reply-To: <alpine.BSF.2.11.1411051159030.1380@mail.fig.ol.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: freeBSD-Questions <freebsd-questions@freebsd.org>
X-BeenThere: freebsd-questions@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: User questions <freebsd-questions.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 14:40:58 -0000

On 05/11/2014 11:13, Trond Endrestøl wrote:
> On Wed, 5 Nov 2014 10:48-0000, Arthur Chance wrote:
>
>> On 05/11/2014 09:27, Trond Endrestøl wrote:
>>> On Wed, 5 Nov 2014 09:06-0000, Arthur Chance wrote:
>>>
>>>> These days I use GPT labelled partitions (/dev/gpt/<label>) exclusively
>>>> when
>>>> creating zfs pools. However, on my latest box, where I have two pools each
>>>> with a single component, "zpool status" lists the components as
>>>> gptid/<uuid>
>>>> rather than gpt/<label>
>>>>
>>>> Is there any way to persuade zfs/zpool to use the GPT label devices rather
>>>> than the gptid devices? Failing that, how do you map gptid's back to the
>>>> underlying disk partitions? It's obvious in this case, but I'm building a
>>>> new
>>>> file server with eight identical disks in a raidz2 set up and am worried
>>>> how
>>>> I'll identify which disk has problems in the future.
>>>
>>> Look at: zpool import -d /dev/gpt some-zpool
>>>
>>
>> I tried that before (after exporting the zpool of course) and it failed.
>> Looking a bit harder, the /dev/gpt device had ceased to exist because the
>> corresponding /dev/gptid device was active. Retasting the disk brought the gpt
>> dive back, and importing with -d worked for one zpool. However, the other has
>> root on it and I'd have to do it from a live memory stick.
>>
>> However, none of this explains why zpool was using the gptid disks - I'd
>> created the pools using gpt labelled disks and that got lost over some reboot,
>> and I'd like to stop that happening again. The problem is that I don't know
>> why it happened. I recently started using boot environments in order to switch
>> from 10.1-RC3 to -RC4, but I'm not sure if that's connected - /boot and the
>> zfs cache are within the b.e. and should have been copied over.
>
> Hmm, I don't believe the cache file is used much these days, unless
> you:
>
> 1. Re-import all your zpools from a live memory stick:
>
> zpool import -d /dev/gpt -o cachefile=/tmp/zpool.cache zpool1
> zpool import -d /dev/gpt -o cachefile=/tmp/zpool.cache zpool2
>
> 2. Copy /tmp/zpool.cache to your b.e.'s /boot/zfs/zpool.cache while
> still running from the live memory stick.
>
> 3. Enable the kernel to consult /boot/zfs/zpool.cache by having these
> three lines in /boot/loader.conf:
>
> zpool_cache_load="YES"
> zpool_cache_type="/boot/zfs/zpool.cache"
> zpool_cache_name="/boot/zfs/zpool.cache"
>

Ah, I wasn't aware of that last part. Thanks.

I seems to me that if the cache isn't usually used and requires special 
loading at boot time, then this problem is going to affect anyone using 
zfs. gptids may be unique, but they're not exactly user friendly.