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

[Cy Schubert]

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 <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.


In message <202008271354.07RDsTeW084744 at slippy.cwsent.com>, Cy Schubert 
writes:
> 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 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 <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.
>