From nobody Fri Nov 29 14:46:29 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y0GGK67gyz5fGfL for ; Fri, 29 Nov 2024 14:46:33 +0000 (UTC) (envelope-from SRS0=jQ2Y=SY=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y0GGK3shZz4LKk; Fri, 29 Nov 2024 14:46:33 +0000 (UTC) (envelope-from SRS0=jQ2Y=SY=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Fri, 29 Nov 2024 15:46:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1732891590; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AQuMZEhYjAz5balUU53GKEknEABDfOgPjpN6n7X4sPY=; b=bPK9d/TU93AsKSb01U0RcaqJ7j/5i37kaAgrEj1mgwlwKgE9MxisLALanByokDNrbZMwZE IQQd+PCImt9wx64ntoOEsmgPBytcHTA5HXpbLpycptEA++fYXxTQIHLQ4pcieiBjzW/wzf xuEZvuL8zaC/DjmkzOK9CfdkgIGoHQFAHOZKvrTn1C6QvRELzqdoomzLAo10wZw/HkamMw 4NJSHGKjZyiZqFxSb3s209GcifUPVXtXBJJBYIgq2W1KrSEABuor6ZCKoU8G+P3cErzP3n CG/cz/yAS0boTFM0sC3xNhhjMFIeTsDAeafw1YF50plIuZdLOjHIghK0fUQgXA== From: Ronald Klop To: Dennis Clarke Cc: Alan Somers , Current FreeBSD Message-ID: <1565006767.9193.1732891589527@localhost> In-Reply-To: <54808a60-a25c-4a26-915f-1ca69387db2a@blastwave.org> References: <5798b0db-bc73-476a-908a-dd1f071bfe43@blastwave.org> <22187e59-b6e9-4f2e-ba9b-f43944d1a37b@blastwave.org> <722a3644-3af6-4ff9-b1ee-022c32872001@blastwave.org> <54808a60-a25c-4a26-915f-1ca69387db2a@blastwave.org> Subject: Re: zpools no longer exist after boot List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9192_1958593303.1732891589524" X-Mailer: Realworks (730.93) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Queue-Id: 4Y0GGK3shZz4LKk X-Spamd-Bar: ---- ------=_Part_9192_1958593303.1732891589524 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Dennis Clarke Datum: vrijdag, 29 november 2024 01:55 Aan: Alan Somers CC: Current FreeBSD Onderwerp: Re: zpools no longer exist after boot > > On 11/28/24 10:55, Alan Somers wrote: > > On Thu, Nov 28, 2024, 9:47AM Dennis Clarke wrote: > > > >> On 11/28/24 09:52, Alan Somers wrote: > >>> On Thu, Nov 28, 2024, 8:45AM Dennis Clarke > >> wrote: > >>> > >> ... > >>> > >>> For "zpool import", the "-c" argument instructs zfs which cachefile to > >>> search for importable pools. "-O", on the other hand, specifies how the > >>> cachefile property should be set after the pool is imported. > >>> > >> > >> I have to wonder what value there is in NOT having the cachefile > >> property set in a zpool ? Certainly given that the zpool RC script > >> really wants to check in a few places and then use those cache files. > >> > >> -- > >> -- > >> Dennis Clarke > >> RISC-V/SPARC/PPC/ARM/CISC > >> UNIX and Linux spoken > >> > > > > Usually the default value for cachefile is sufficient. In fact, the only > > time I've ever needed to set cachefile has been when I DON'T want the pool > > to import at boot. I wonder if there was some other reason, since resolved, > > why your pools didn't import the first time. And subsequently they didn't > > import because you set the cachefile to a non default value? > > > > I am at a loss. Really. > > Getting the iSCSI stuff working was a real treat and this just makes > things even more strange. I really do not know. > > > > > -- > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > > > > > Hi, I hope I can clarify a bit for you. See 'man zpoolprops' and search for: cachefile=path|none. The property 'cachefile' is not stored on disk. It is only used at the moment of import or creation of a pool to tell the 'zpool import' command (or kernel) where to store the information about imported zpools. So as the property is not stored on disk, after a reboot the zpool property 'cachefile' is always empty. It is more like a pseudo-property. Maybe it would be more clear if it had its own command line option in zpool import. If you don't pass the zpool cachefile property to zpool import it will default to /etc/zfs/zpool.cache. What happend on boot: 1. the boot loader looks at the boot-disk what pool to start from. This does not use any cachefile, it just looks at the disk blocks (because the cachefile is not available yet, as the FS is not mounted yet). 2. the init process /etc/rc.d/zpool looks in /etc/zfs/zpool.cache for extra pools to import. (as shown in a previous mail) 3. the init process /etc/rc.d/zfs mounts the zfs filesystems. There is not much more to it for local disks. As you are using iscsi also, I think you have a little bit more configuration as the iscsi device appears after /etc/rc.d/zpool & /etc/rc.d/zfs is up and running. I will answer on the iscsi part in another email. NB: I also have systems with multiple pools. I have never changed the cachefile property. If this doesn't clarify the process to you, would you be able to tell more about what you mean with 'I am at a loss'? Regards, Ronald. PS: I might have some details wrong here, other might be more knowledgeable about this, but I think this is the bigger picture. ------=_Part_9192_1958593303.1732891589524 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Dennis Clarke <dclarke@blastwave.org>
Datum: vrijdag, 29 november 2024 01:55
Aan: Alan Somers <asomers@freebsd.org>
CC: Current FreeBSD <freebsd-current@freebsd.org>
Onderwerp: Re: zpools no longer exist after boot

On 11/28/24 10:55, Alan Somers wrote:
> On Thu, Nov 28, 2024, 9:47AM Dennis Clarke <dclarke@blastwave.org> wrote:
>
>> On 11/28/24 09:52, Alan Somers wrote:
>>> On Thu, Nov 28, 2024, 8:45AM Dennis Clarke <dclarke@blastwave.org>
>> wrote:
>>>
>> ...
>>>
>>> For "zpool import", the "-c" argument instructs zfs which cachefile to
>>> search for importable pools. "-O", on the other hand, specifies how the
>>> cachefile property should be set after the pool is imported.
>>>
>>
>> I have to wonder what value there is in NOT having the cachefile
>> property set in a zpool ?  Certainly given that the zpool RC script
>> really wants to check in a few places and then use those cache files.
>>
>> --
>> --
>> Dennis Clarke
>> RISC-V/SPARC/PPC/ARM/CISC
>> UNIX and Linux spoken
>>
>
> Usually the default value for cachefile is sufficient. In fact, the only
> time I've ever needed to set cachefile has been when I DON'T want the pool
> to import at boot. I wonder if there was some other reason, since resolved,
> why your pools didn't import the first time. And subsequently they didn't
> import because you set the cachefile to a non default value?
>

I am at a loss.  Really.

Getting the iSCSI stuff working was a real treat and this just makes
things even more strange. I really do not know.




-- 
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

 


Hi,

I hope I can clarify a bit for you.

See 'man zpoolprops' and search for: cachefile=path|none.

The property 'cachefile' is not stored on disk. It is only used at the moment of import or creation of a pool to tell the 'zpool import' command (or kernel) where to store the information about imported zpools.
So as the property is not stored on disk, after a reboot the zpool property 'cachefile' is always empty. It is more like a pseudo-property. Maybe it would be more clear if it had its own command line option in zpool import.
If you don't pass the zpool cachefile property to zpool import it will default to /etc/zfs/zpool.cache.

What happend on boot:
1. the boot loader looks at the boot-disk what pool to start from. This does not use any cachefile, it just looks at the disk blocks (because the cachefile is not available yet, as the FS is not mounted yet).
2. the init process /etc/rc.d/zpool looks in /etc/zfs/zpool.cache for extra pools to import. (as shown in a previous mail)
3. the init process /etc/rc.d/zfs mounts the zfs filesystems.

There is not much more to it for local disks. As you are using iscsi also, I think you have a little bit more configuration as the iscsi device appears after /etc/rc.d/zpool & /etc/rc.d/zfs is up and running. I will answer on the iscsi part in another email.

NB: I also have systems with multiple pools. I have never changed the cachefile property.

If this doesn't clarify the process to you, would you be able to tell more about what you mean with 'I am at a loss'?

Regards,
Ronald.

PS: I might have some details wrong here, other might be more knowledgeable about this, but I think this is the bigger picture. ------=_Part_9192_1958593303.1732891589524--