freebsd stable - May 2016 - State of unionfs?

Hi, all,

we were looking for a way to get overlay/copy-on-write mounts for
ZFS datasets to ease jail management.

Google turned up this old thread:
https://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009221.html

So, clearly in September 2010 mount_unionfs(8) was not supported
for ZFS datasets.

A quick check on a current RELENG-10.3 system showed that this has
changed .Union-mounting one dataset on top of another does indeed
work at a superficial glance.

Yet the manpage for mount_unionfs(8) still contains this disturbing
note:

BUGS
     THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T
WORK)
     AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR OWN
     RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.  BATTERIES NOT INCLUDED.

Is this still the case? Are there alternatives to our approach.

What we would like to implement is e.g. a standard pre-populated /etc for each
jail with only modified files being written to a separate per-jail dataset.
Much like NanoBSD does when populating the /etc mfs at boot.

While we can create a clone from a central snapshot for each jail, the
problem with this way is that we cannot exchange the base snapshot later,
e.g. after a major system update for the jail in question. Which is precisely
the intention in the first place ;-)

Thanks for any hints
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info at punkt.de       http://www.punkt.de
Gf: J?rgen Egeling      AG Mannheim 108285

On 18/05/2016 10:27, Patrick M. Hausen wrote:
> Hi, all,
> 
> we were looking for a way to get overlay/copy-on-write mounts for
> ZFS datasets to ease jail management.
> 
> Google turned up this old thread:
> https://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009221.html
> 
> So, clearly in September 2010 mount_unionfs(8) was not supported
> for ZFS datasets.
> 
> A quick check on a current RELENG-10.3 system showed that this has
> changed .Union-mounting one dataset on top of another does indeed
> work at a superficial glance.
> 
> Yet the manpage for mount_unionfs(8) still contains this disturbing
> note:
> 
> BUGS
>      THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T
WORK)
>      AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
OWN
>      RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.  BATTERIES NOT INCLUDED.
> 
> Is this still the case? Are there alternatives to our approach.
> 
> What we would like to implement is e.g. a standard pre-populated /etc for
each
> jail with only modified files being written to a separate per-jail dataset.
> Much like NanoBSD does when populating the /etc mfs at boot.
> 
> While we can create a clone from a central snapshot for each jail, the
> problem with this way is that we cannot exchange the base snapshot later,
> e.g. after a major system update for the jail in question. Which is
precisely
> the intention in the first place ;-)
> 
> Thanks for any hints
> Patrick
> 
I've used unionfs with zfs for a while now. Seems ok.
But beware of nesting any mounts into either lower or upper layer. Files
created in there may not appear in the right place. They used to, but
that broke at some point.

I'm now moving away from unionfs, and doing a simple zfs clone. When
it's time to upgrade, copy data files separately. Config files are
tracked with Mercurial.