Date: Thu, 27 Aug 2020 11:51:37 -0500 From: "Brandon Bergren" <bdragon@FreeBSD.org> To: "Kyle Evans" <kevans@freebsd.org>, "Andriy Gapon" <avg@freebsd.org> Cc: "Cy Schubert" <Cy.Schubert@cschubert.com>, "Cy Schubert" <cy@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r364817 - head/libexec/rc/rc.d Message-ID: <c67509ce-ccd6-4f19-8c04-7c919d3c09b2@www.fastmail.com> In-Reply-To: <CACNAnaHw-QM_nFZ%2BjhLwjdUEg9WceybhhcBep6oiiNv-EBH6cQ@mail.gmail.com> References: <202008261313.07QDDwRm040119@repo.freebsd.org> <7e55d429-482b-2277-b340-2b85c687440e@FreeBSD.org> <202008271350.07RDoGqn055838@slippy.cwsent.com> <202008271354.07RDsTeW084744@slippy.cwsent.com> <202008271403.07RE3U56090900@slippy.cwsent.com> <CACNAnaGNJBcBp4tpUL5EK772BwAC02R_dQCMcohqHnzQ50aboA@mail.gmail.com> <CACNAnaFbFd%2BsRigaO5W88LFYXDKgsJC%2BU5rYXZFMqUgMiad4TQ@mail.gmail.com> <5e96ff14-1d81-c42f-21f6-1ae55aa9ce76@FreeBSD.org> <CACNAnaHw-QM_nFZ%2BjhLwjdUEg9WceybhhcBep6oiiNv-EBH6cQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 27, 2020, at 11:19 AM, Kyle Evans wrote: > On Thu, Aug 27, 2020 at 10:59 AM Andriy Gapon <avg@freebsd.org> wrote: > > > > On 2020-08-27 17:06, Kyle Evans wrote: > > > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans <kevans@freebsd.org> wrote: > > >> > > >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > >>> > > >>> What would you suggest in this case, where /etc/zfs/zpool.cache is newer > > >>> than /boot/zfs/zpool.cache? > > >>> > > >>> slippy$ lh /boot/zfs/zpool.cache /etc/zfs/zpool.cache > > >>> -rw-r--r-- 1 root wheel 4.6K Aug 25 07:19 /boot/zfs/zpool.cache > > >>> -rw-r--r-- 1 root wheel 4.7K Aug 27 06:20 /etc/zfs/zpool.cache > > >>> slippy$ > > >>> > > >>> Something like, for I in $(ls -t /etc/zfs/zpool.cache > > >>> /boot/zfs/zpool.cache) with the break? > > >>> > > >> > > >> /etc/zfs/zpool.cache is the new location and should generally be > > >> favored if it exists, I reckon. > > > > > > I retract the above. :-) ls -t makes sense. > > > > > > > I actually was about to agree with your first suggestion. > > > > I think it's the correct long-term solution, but it kind of depends on > what we're thinking now- if we expect one might test-boot a disk on an > older FreeBSD/ZFS that's still using /boot, there's a chance it will > contain the more recent data. > FWIW, on powerpc64, using /etc/zfs/zpool.cache is great because it avoids the problem of having to unmount /boot (which is an msdos filesystem because peitiboot doesn't understand ufs or zfs) to update the copy of zpool.cache that 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 written is to set the cachefile property on the zpool to the specific path. The correct behavior regarding boot time auto import of pools is to honor that property as found on the pool the boot filesystem was on, so that other pools sharing the same cachefile path will be imported. Multiple cache files and pools not actually listed in a cachefile are valid scenarios for pools. -- Brandon Bergren bdragon@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c67509ce-ccd6-4f19-8c04-7c919d3c09b2>