10.3 zpool/var canmount = off?

[Oscar Hodgson]

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.

Oscar
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Matthew Seaman]

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

Cheers,

Matthew

[Brandon J. Wandersee]

Matthew Seaman writes:

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

Matthew covered all the big stuff, but the ability to create dataset
trees with non-hierarchical mountpoints, or an unmounted dataset as the
root of a dataset tree, is actually a very useful administration
trick. Boot environments are one example, but it also lets you manage
and easily roll back all parts of a system that are related to each
other, but the files for which are stored in different parts of the
filesystem. You could, for example, create a dataset tree for every
component of an Apache or Nginx configuration. I have a tree of
filesystems for everything related to ports/packages except distfiles,
so I can roll everything back in lock-step if an upgrade goes bad while
avoiding having to download everything again.

--
:: Brandon J. Wandersee
:: brandon....@gmail.com
:: --------------------------------------------------
:: 'The best design is as little design as possible.'
:: --- Dieter Rams ----------------------------------

[Kevin P. Neal]

On Fri, Sep 16, 2016 at 04:18:31PM -0500, Brandon J. Wandersee wrote:
>
> Matthew Seaman writes:
>
> > 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.

> I have a tree of
> filesystems for everything related to ports/packages except distfiles,
> so I can roll everything back in lock-step if an upgrade goes bad while
> avoiding having to download everything again.

Does anyone know for certain that a pkg'ized base system will kill the
ability to keep the base system distinct from /usr/local?

I keep my /var/db/ports and /var/db/pkg trees symlinked so they are in
/usr/local to guarantee that they are always in sync with the software
that is installed. But a pkg'ized base kills my ability to keep /usr/local
correctly accounted for while doing a fresh install of base, say, in a new
ZFS dataset.

--
Kevin P. Neal http://www.pobox.com/~kpn/

"I like being on The Daily Show." - Kermit the Frog, Feb 13 2001

[Brandon J. Wandersee]

Kevin P. Neal writes:

> On Fri, Sep 16, 2016 at 04:18:31PM -0500, Brandon J. Wandersee wrote:
>>
>> Matthew Seaman writes:
>>
>> > 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.
>
>> I have a tree of
>> filesystems for everything related to ports/packages except distfiles,
>> so I can roll everything back in lock-step if an upgrade goes bad while
>> avoiding having to download everything again.
>
> Does anyone know for certain that a pkg'ized base system will kill the
> ability to keep the base system distinct from /usr/local?
>
> I keep my /var/db/ports and /var/db/pkg trees symlinked so they are in
> /usr/local to guarantee that they are always in sync with the software
> that is installed. But a pkg'ized base kills my ability to keep /usr/local
> correctly accounted for while doing a fresh install of base, say, in a new
> ZFS dataset.

Assuming I understand you correctly: it seems one of the things keeping
pkgbase out of the mainline right now is the need to update pkg(8) to
handle base and application package installation, upgrade, and removal
processes separately (e.g. `pkg delete -a` will destroy the system, `pkg
upgrade` will upgrade both system and application packages, etc.). It's
an acknowledged problem, but I don't know how far along the work is
right now. Surely something is being done about it, or folks who upgrade
RELEASEs from source or track development branches, while using packages
instead of ports, will wind up with broken systems.

https://wiki.freebsd.org/PkgBase

--
:: Brandon J. Wandersee
:: brandon....@gmail.com
:: --------------------------------------------------
:: 'The best design is as little design as possible.'
:: --- Dieter Rams ----------------------------------