Fwd: Jailcfg - A new tool for creating small(!) jails

[Merijn Verstraaten]

On Sat, 13 Feb 2010 01:54:22 +0100, Philipp Wuensche  
<cryx-freebsd at h3q.com> wrote:
>> The only data that is collected after that is user data which is a good
>> thing with no extra cost of system mount points and disk usage.
>
> Thats only true until the first update of the freebsd-userland inside
> the jail. The moment you need to update the freebsd-userland inside the
> jail, it will use additional space and all the advantages of this idea
> are gone.

This is true, but not much of a problem in practice. I use the same  
approach combined with a Nuke & Pave upgrade process. I simply upgrade the  
original base installation, create a new snapshot and instead of upgrading  
the individual jails I just delete them and create a new clone of the new  
snapshot. Since I nullfs mount the actual user data from another  
filesystem this requires nothing on the jail. I install from packages I  
compile myself, so the port installation time is near zero and I can just  
copy over the config files from the old jail to the new one. Most of these  
steps can be trivially automated. This is also a good remedy from  
preventing your jails from unintentionally diverging from their common  
configuration too much. Of course when background deduplication gets  
ported to ZFS it all becomes moot and we can have insane space saving for  
jails.

> Using clone will also create a direct dependency between the snapshots
> and the cloned filesystems. As long as the clone exists, the snapshot
> has to be kept. This is only resolvable by using zfs send/recv which
> will, again, use additional space.

I don't really see how the dependency is an issue. Could you perhaps  
explain how/why this matters?

Kind regards,
Merijn Verstraaten