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

[Cy Schubert]

In message <202008271350.07RDoGqn055838 at slippy.cwsent.com>, Cy Schubert 
writes:
> In message <7e55d429-482b-2277-b340-2b85c687440e at 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 <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.