From owner-freebsd-jail@FreeBSD.ORG Sat Feb 13 01:30:02 2010 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A96781065670 for ; Sat, 13 Feb 2010 01:30:02 +0000 (UTC) (envelope-from merijn@inconsistent.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC418FC0C for ; Sat, 13 Feb 2010 01:30:01 +0000 (UTC) Received: from twilight.fritz.box (inconsistent.nl [83.163.46.169]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id o1D1Et2p072713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 02:14:56 +0100 (CET) (envelope-from merijn@inconsistent.nl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Philipp Wuensche" , jhell References: <4B75F83E.4000400@h3q.com> Date: Sat, 13 Feb 2010 02:14:55 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Merijn Verstraaten" Organization: Inconsistent Message-ID: In-Reply-To: <4B75F83E.4000400@h3q.com> User-Agent: Opera Mail/10.10 (MacIntel) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Christer Solskogen , freebsd-jail@freebsd.org Subject: Re: Fwd: Jailcfg - A new tool for creating small(!) jails X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 01:30:02 -0000 On Sat, 13 Feb 2010 01:54:22 +0100, Philipp Wuensche 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