10.3 zpool/var canmount = off?
matthew at FreeBSD.org
Wed Sep 14 15:19:16 UTC 2016
On 2016/09/14 15:47, Oscar Hodgson wrote:
> New 10.3 install and I just noted that canmount is set off (local).
> So it serves only to provide a root for other var pools (okay) and a
> number of /var sub-directories wind up on the root file system (e.g.
> /var/db, /var/cache).
> Is there any specific reason why that choice was made?
> I working on updating / replacing a 9.0 mfsroot image we use to pxe
> boot machines (and decided to pass on 9.3). That image set up /var
> within rc.conf (varmfs=“YES”, populate_var=“YES”), but everything
> there disappears when the machine powers off at the end of the day …
> and part of my objective is to minimize the size of root.
> Mostly curiosity (and my next step it to “fix” canmount), just
> thought I’d ask.
The layout generated by the installer puts as much as possible into a
single 'root' ZFS set up as a boot environment 'zroot/ROOT/default' that
you can immediately drop into beadm(1) to manage updates etc. This
single ZFS is then easier to manage for operations like using 'zfs send'
to clone the system somewhere else. While beadm(1) will cope perfectly
well with a more complicated tree of ZFSes in each boot environment,
having a tree of ZFSes does make the tricks you can do with zfs
send/recv quite a lot more bothersome.
The root ZFS contains large chunks of the content under /var by default,
but not all of it.
The point of having zroot/var (with canmount=off) that just acts as a
placeholder is so that eg. zroot/var/log or zroot/var/tmp (which you'll
see have 'canmount=on') get mounted in the right location in the file
system without becoming part of any boot environment. That means
there's only one copy of those filesystems and it always gets mounted
every time you reboot -- which is really what you want for eg. /var/log
but not correct for boot environments in general. Usually you'll have
several available, but only one of them should be mounted and active.
Your current setup using pxeboot and varmfs is behaving as expected.
varmfs creates /var as a memory file system -- ie. one without a long
lived backing store. It's expected to be destroyed when the system
shuts down and recreated from scratch on bootup.
If you want content under /var to survive reboots (for example, the
package database in /var/db/pkg is a PITA to have to regenerate...),
then you'll need to store it on something other than a mfs -- and you
can use the 'canmount=off' concept to create a ZFS overlay on top of an
mfs to do that. (Although getting everything mounted in the right
sequence there is going to be a bit tricky.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 972 bytes
Desc: OpenPGP digital signature
More information about the freebsd-questions