Date: Sat, 13 Feb 2010 02:14:55 +0100 From: "Merijn Verstraaten" <merijn@inconsistent.nl> To: "Philipp Wuensche" <cryx-freebsd@h3q.com>, jhell <jhell@dataix.net> Cc: Christer Solskogen <christer.solskogen@gmail.com>, freebsd-jail@freebsd.org Subject: Re: Fwd: Jailcfg - A new tool for creating small(!) jails Message-ID: <op.u71ke4f84534sa@twilight.fritz.box> In-Reply-To: <4B75F83E.4000400@h3q.com> References: <c1a0d1561002110733y575d0681t4feb917deabce531@mail.gmail.com> <c1a0d1561002112323h1902248bj7be343d4e1083687@mail.gmail.com> <alpine.BSF.2.00.1002120250310.61799@pragry.qngnvk.ybpny> <4B75F83E.4000400@h3q.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Feb 2010 01:54:22 +0100, Philipp Wuensche <cryx-freebsd@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.u71ke4f84534sa>