svn commit: r364817 - head/libexec/rc/rc.d

[Cy Schubert]

In message <c8c2eda5-bd77-7754-ad83-98c40840b584 at FreeBSD.org>, Andriy Gapon 
wri
tes:
> On 27/08/2020 19:51, Brandon Bergren wrote:
> > FWIW, on powerpc64, using /etc/zfs/zpool.cache is great because it avoids t
> he problem of having to unmount /boot (which is an msdos filesystem because p
> eitiboot doesn't understand ufs or zfs) to update the copy of zpool.cache tha
> t is on the root filesystem in /boot instead of only changing the one in the 
> runtime /boot (which was mounted on top, and is never useful because it's not
>  mounted at the time that zpool.cache is actually needed to import pools.)
> > 
> > In any case, the correct way on ZFS to control where the cachefile is writt
> en is to set the cachefile property on the zpool to the specific path. The co
> rrect behavior regarding boot time auto import of pools is to honor that prop
> erty as found on the pool the boot filesystem was on, so that other pools sha
> ring the same cachefile path will be imported. Multiple cache files and pools
>  not actually listed in a cachefile are valid scenarios for pools.
>
>
> Just want to express my complete agreement.

Agreed with the above, however:

I still think that using a zpool import in rc.d is a regression. I 
understand why the OpenZFS folks did what they did. Linux with it's 
filesystem agnostic grub and initramfs monstrosity requires that they 
externalize this. I'm not happy about the regression but understand why 
they did it.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy at nwtime.org>    Web:  https://nwtime.org

	The need of the many outweighs the greed of the few.