Re: svn commit: r364817 - head/libexec/rc/rc.d
In message , 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 FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 27/08/2020 19:51, Brandon Bergren wrote: > 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. Just want to express my complete agreement. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020, at 11:19 AM, Kyle Evans wrote: > On Thu, Aug 27, 2020 at 10:59 AM Andriy Gapon wrote: > > > > On 2020-08-27 17:06, Kyle Evans wrote: > > > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: > > >> > > >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert > > >> 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 bdra...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020 at 10:59 AM Andriy Gapon wrote: > > On 2020-08-27 17:06, Kyle Evans wrote: > > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: > >> > >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert > >> 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. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 2020-08-27 16:54, Cy Schubert wrote: > In message <202008271350.07rdogqn055...@slippy.cwsent.com>, Cy Schubert > writes: >> In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon >> wri >> tes: >>> On 26/08/2020 16:13, Cy Schubert wrote: Author: cy Date: Wed Aug 26 13:13:57 2020 New Revision: 364817 URL: https://svnweb.freebsd.org/changeset/base/364817 Log: As of r364746 (OpenZFS import) existing ZPOOLs are not imported prior to zvol and mountcritlocal resulting in ZVOLs (swap and >>> >>> I probably missed some discussion, so I am curious why that is. >> >> This is because r364746 added the code below to rc.d/zfs and by then it was >> too late. I simply moved it to a new file that allowed rc.d/zvol and >> rc.d/mountcritlocal with legacy mounts to work again. This was copied from >> rc.d/zfs, which was added by r364746. There was no need for a zpool import >> under the previous version of ZFS, whereas it appears that OpenZFS requires >> it. > > Let me add, one could say this is a regression. Yes, I was actually curious about this change in ZFS driver behavior. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 2020-08-27 17:06, Kyle Evans wrote: > On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: >> >> On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert >> 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. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020 at 9:05 AM Kyle Evans wrote: > > On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert 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. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On Thu, Aug 27, 2020 at 9:03 AM Cy Schubert 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. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
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?
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
In message <202008271354.07rdstew084...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <202008271350.07rdogqn055...@slippy.cwsent.com>, Cy Schubert
> writes:
> > In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon
>
> > wri
> > tes:
> > > On 26/08/2020 16:13, Cy Schubert wrote:
> > > > Author: cy
> > > > Date: Wed Aug 26 13:13:57 2020
> > > > New Revision: 364817
> > > > URL: https://svnweb.freebsd.org/changeset/base/364817
> > > >
> > > > Log:
> > > > As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> > > > prior to zvol and mountcritlocal resulting in ZVOLs (swap and
> > >
> > > I probably missed some discussion, so I am curious why that is.
> >
> > This is because r364746 added the code below to rc.d/zfs and by then it was
>
> > too late. I simply moved it to a new file that allowed rc.d/zvol and
> > rc.d/mountcritlocal with legacy mounts to work again. This was copied from
> > rc.d/zfs, which was added by r364746. There was no need for a zpool import
> > under the previous version of ZFS, whereas it appears that OpenZFS requires
>
> > it.
>
> Let me add, one could say this is a regression.
>
> >
> > >
> > > > virtual machine UFS filesystems) being unavailable, leading to
> > > > boot failures.
> > > > We move the zpool import from zfs to a new zpool script, with the
> > > > -N option to avoid mounting datasets while making the ZPOOL's
> > > > datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> > > > available for subsequent use for swap (in the zvol rc sript) or
> > > > for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
> > > >
> > > > Reviewed by: freqlabs (previous version)
> > > > Differential Revision:https://reviews.freebsd.org/D26185
> > > >
> > > > Added:
> > > > head/libexec/rc/rc.d/zpool (contents, props changed)
> > > [snip]
> > > > +zpool_start()
> > > > +{
> > > > + local cachefile
> > > > +
> > > > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > > > + if [ -r $cachefile ]; then
> > > > + zpool import -c $cachefile -a -N
> > >
> > > I would add a break here, so that pools are imported either from one cach
> e
> > fi
> > > le
> > > or the other but not both. It makes sense to have two cache file definit
> io
> > ns
> > > for migration, but I think that it does not make sense to split pools bet
> we
> > en
> > > the cache files.
> >
> > Agreed.
> >
> > >
> > > > + fi
> > > > + done
> > > > +}
> > >
> > >
> > > --
> > > Andriy Gapon
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: https://FreeBSD.org
> NTP: Web: https://nwtime.org
>
> The need of the many outweighs the greed of the few.
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
In message <202008271350.07rdogqn055...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon
> wri
> tes:
> > On 26/08/2020 16:13, Cy Schubert wrote:
> > > Author: cy
> > > Date: Wed Aug 26 13:13:57 2020
> > > New Revision: 364817
> > > URL: https://svnweb.freebsd.org/changeset/base/364817
> > >
> > > Log:
> > > As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> > > prior to zvol and mountcritlocal resulting in ZVOLs (swap and
> >
> > I probably missed some discussion, so I am curious why that is.
>
> This is because r364746 added the code below to rc.d/zfs and by then it was
> too late. I simply moved it to a new file that allowed rc.d/zvol and
> rc.d/mountcritlocal with legacy mounts to work again. This was copied from
> rc.d/zfs, which was added by r364746. There was no need for a zpool import
> under the previous version of ZFS, whereas it appears that OpenZFS requires
> it.
Let me add, one could say this is a regression.
>
> >
> > > virtual machine UFS filesystems) being unavailable, leading to
> > > boot failures.
> > > We move the zpool import from zfs to a new zpool script, with the
> > > -N option to avoid mounting datasets while making the ZPOOL's
> > > datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> > > available for subsequent use for swap (in the zvol rc sript) or
> > > for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
> > >
> > > Reviewed by:freqlabs (previous version)
> > > Differential Revision: https://reviews.freebsd.org/D26185
> > >
> > > Added:
> > > head/libexec/rc/rc.d/zpool (contents, props changed)
> > [snip]
> > > +zpool_start()
> > > +{
> > > + local cachefile
> > > +
> > > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > > + if [ -r $cachefile ]; then
> > > + zpool import -c $cachefile -a -N
> >
> > I would add a break here, so that pools are imported either from one cache
> fi
> > le
> > or the other but not both. It makes sense to have two cache file definitio
> ns
> > for migration, but I think that it does not make sense to split pools betwe
> en
> > the cache files.
>
> Agreed.
>
> >
> > > + fi
> > > + done
> > > +}
> >
> >
> > --
> > Andriy Gapon
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
In message <7e55d429-482b-2277-b340-2b85c6874...@freebsd.org>, Andriy Gapon
wri
tes:
> On 26/08/2020 16:13, Cy Schubert wrote:
> > Author: cy
> > Date: Wed Aug 26 13:13:57 2020
> > New Revision: 364817
> > URL: https://svnweb.freebsd.org/changeset/base/364817
> >
> > Log:
> > As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> > prior to zvol and mountcritlocal resulting in ZVOLs (swap and
>
> I probably missed some discussion, so I am curious why that is.
This is because r364746 added the code below to rc.d/zfs and by then it was
too late. I simply moved it to a new file that allowed rc.d/zvol and
rc.d/mountcritlocal with legacy mounts to work again. This was copied from
rc.d/zfs, which was added by r364746. There was no need for a zpool import
under the previous version of ZFS, whereas it appears that OpenZFS requires
it.
>
> > virtual machine UFS filesystems) being unavailable, leading to
> > boot failures.
> > We move the zpool import from zfs to a new zpool script, with the
> > -N option to avoid mounting datasets while making the ZPOOL's
> > datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> > available for subsequent use for swap (in the zvol rc sript) or
> > for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
> >
> > Reviewed by: freqlabs (previous version)
> > Differential Revision:https://reviews.freebsd.org/D26185
> >
> > Added:
> > head/libexec/rc/rc.d/zpool (contents, props changed)
> [snip]
> > +zpool_start()
> > +{
> > + local cachefile
> > +
> > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > + if [ -r $cachefile ]; then
> > + zpool import -c $cachefile -a -N
>
> I would add a break here, so that pools are imported either from one cache fi
> le
> or the other but not both. It makes sense to have two cache file definitions
> for migration, but I think that it does not make sense to split pools between
> the cache files.
Agreed.
>
> > + fi
> > + done
> > +}
>
>
> --
> Andriy Gapon
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364817 - head/libexec/rc/rc.d
On 26/08/2020 16:13, Cy Schubert wrote:
> Author: cy
> Date: Wed Aug 26 13:13:57 2020
> New Revision: 364817
> URL: https://svnweb.freebsd.org/changeset/base/364817
>
> Log:
> As of r364746 (OpenZFS import) existing ZPOOLs are not imported
> prior to zvol and mountcritlocal resulting in ZVOLs (swap and
I probably missed some discussion, so I am curious why that is.
> virtual machine UFS filesystems) being unavailable, leading to
> boot failures.
> We move the zpool import from zfs to a new zpool script, with the
> -N option to avoid mounting datasets while making the ZPOOL's
> datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
> available for subsequent use for swap (in the zvol rc sript) or
> for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
>
> Reviewed by:freqlabs (previous version)
> Differential Revision: https://reviews.freebsd.org/D26185
>
> Added:
> head/libexec/rc/rc.d/zpool (contents, props changed)
[snip]
> +zpool_start()
> +{
> + local cachefile
> +
> + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> + if [ -r $cachefile ]; then
> + zpool import -c $cachefile -a -N
I would add a break here, so that pools are imported either from one cache file
or the other but not both. It makes sense to have two cache file definitions
for migration, but I think that it does not make sense to split pools between
the cache files.
> + fi
> + done
> +}
--
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r364817 - head/libexec/rc/rc.d
Author: cy
Date: Wed Aug 26 13:13:57 2020
New Revision: 364817
URL: https://svnweb.freebsd.org/changeset/base/364817
Log:
As of r364746 (OpenZFS import) existing ZPOOLs are not imported
prior to zvol and mountcritlocal resulting in ZVOLs (swap and
virtual machine UFS filesystems) being unavailable, leading to
boot failures.
We move the zpool import from zfs to a new zpool script, with the
-N option to avoid mounting datasets while making the ZPOOL's
datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
available for subsequent use for swap (in the zvol rc sript) or
for UFS or other filesystems in fstab(5), mounted by mountcritlocal.
Reviewed by: freqlabs (previous version)
Differential Revision:https://reviews.freebsd.org/D26185
Added:
head/libexec/rc/rc.d/zpool (contents, props changed)
Modified:
head/libexec/rc/rc.d/Makefile
head/libexec/rc/rc.d/mountcritlocal
head/libexec/rc/rc.d/zfs
head/libexec/rc/rc.d/zvol
Modified: head/libexec/rc/rc.d/Makefile
==
--- head/libexec/rc/rc.d/Makefile Wed Aug 26 12:54:18 2020
(r364816)
+++ head/libexec/rc/rc.d/Makefile Wed Aug 26 13:13:57 2020
(r364817)
@@ -318,6 +318,7 @@ CONFGROUPS+=ZFS
ZFS+= zfs
ZFS+= zfsbe
ZFS+= zfsd
+ZFS+= zpool
ZFS+= zvol
.endif
Modified: head/libexec/rc/rc.d/mountcritlocal
==
--- head/libexec/rc/rc.d/mountcritlocal Wed Aug 26 12:54:18 2020
(r364816)
+++ head/libexec/rc/rc.d/mountcritlocal Wed Aug 26 13:13:57 2020
(r364817)
@@ -4,7 +4,7 @@
#
# PROVIDE: mountcritlocal
-# REQUIRE: root hostid_save mdconfig
+# REQUIRE: root hostid_save mdconfig zvol
# KEYWORD: nojail shutdown
. /etc/rc.subr
Modified: head/libexec/rc/rc.d/zfs
==
--- head/libexec/rc/rc.d/zfsWed Aug 26 12:54:18 2020(r364816)
+++ head/libexec/rc/rc.d/zfsWed Aug 26 13:13:57 2020(r364817)
@@ -25,13 +25,6 @@ zfs_start_jail()
zfs_start_main()
{
- local cachefile
-
- for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
- if [ -r $cachefile ]; then
- zpool import -c $cachefile -a
- fi
- done
zfs mount -va
zfs share -a
if [ ! -r /etc/zfs/exports ]; then
Added: head/libexec/rc/rc.d/zpool
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/libexec/rc/rc.d/zpool Wed Aug 26 13:13:57 2020(r364817)
@@ -0,0 +1,31 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+
+# PROVIDE: zpool
+# REQUIRE: hostid
+# BEFORE: zvol mountcritlocal
+# KEYWORD: nojail
+
+. /etc/rc.subr
+
+name="zpool"
+desc="Import ZPOOLs"
+rcvar="zfs_enable"
+start_cmd="zpool_start"
+required_modules="zfs"
+
+zpool_start()
+{
+ local cachefile
+
+ for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
+ if [ -r $cachefile ]; then
+ zpool import -c $cachefile -a -N
+ fi
+ done
+}
+
+load_rc_config $name
+run_rc_command "$1"
Modified: head/libexec/rc/rc.d/zvol
==
--- head/libexec/rc/rc.d/zvol Wed Aug 26 12:54:18 2020(r364816)
+++ head/libexec/rc/rc.d/zvol Wed Aug 26 13:13:57 2020(r364817)
@@ -4,7 +4,7 @@
#
# PROVIDE: zvol
-# REQUIRE: hostid
+# REQUIRE: zpool
# BEFORE: dumpon
# KEYWORD: nojail
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
