From owner-freebsd-stable@freebsd.org Thu May 19 06:31:12 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A975B41138 for ; Thu, 19 May 2016 06:31:12 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB4CD16A4 for ; Thu, 19 May 2016 06:31:11 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id bi2so109399805igb.0 for ; Wed, 18 May 2016 23:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=MmHKmCanbXQuf/jARl55Sx8i5UOmBiIlb5/5GBVAxlE=; b=x9xn0G64inFV2sCusAGn0DbgzdXgWlr0OpKcaGw1IZdzOvJF6C2bG0BtdTztoaSGFo CoRDK/rBDRqgpCFTSmn/1egiRXXRW4bWP2E6JWPdLjFhI+h2/N4cBAbbLGHfed4RaIFE djm+s/e/Cy4fAzivK7kr5IH7RpLyyLbe9JkqKoUnfGUEzwW0ysZNb8TM00qaWIZgC94D u5V8VoUpEQCEzPLgjUAHIUq2fEAR2moXgjaiZ+IM4ywh+PUjNU8024vwpAxoSqld7DoR 8k6pSXf19qZpOihJzhXItJxQGzwiFSzxGvOCRMlKLmWVEUmjcBOGZPSYYCNzFDldeV81 j8xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MmHKmCanbXQuf/jARl55Sx8i5UOmBiIlb5/5GBVAxlE=; b=eF8sPtoEKSHjva8Saflj7wmJWLJt7X80hvyfzqyMWKiObAtjpqitqpM+0j/X24B9ey anReFV6L+sPclNH7pPnjLoSXxUw8yStzORb5i3j4q10QNNv5in6e1OB9NBXPS40EOgT9 vXPI9eVdHoTUXG6s+lZPwMSqAJZEL8AmUkHH8Z2Rrp71nkCbWcSEnjhV+WbHEmyZvvHX MsMfqlaXJVE5URl5X146VT64M7XSltj1xbqJ5OKrXfaMYEdsdNdK47jrM+bo4guEzXgM NlrHyBHq8uV45CzwPap7S4fwqoJFTRNhdsAySVoN+F6jrZ0xRm5oeLhIK0n4uQ4Vp4Ha aFRQ== X-Gm-Message-State: AOPr4FVo/5U5X9uPDdS2PWGQXCq2SdKKmYV3MISz5sNCg3CDOc5K4qJZSyLNdZyN8RJNN/XUxKXZ0JfXBcXvjA== MIME-Version: 1.0 X-Received: by 10.50.108.196 with SMTP id hm4mr288870igb.63.1463639471372; Wed, 18 May 2016 23:31:11 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.140.8 with HTTP; Wed, 18 May 2016 23:31:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2016 23:31:11 -0700 X-Google-Sender-Auth: CwPGn4Ez2qFe-XtXtJYxgA30oAA Message-ID: Subject: Re: State of unionfs? From: "K. Macy" To: Johannes Totz Cc: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 06:31:12 -0000 Everything I've been told is that unionfs has essentially never worked right. FreeBSD's VFS semantics and vnode life cycle make it very difficult to implement correctly. -M On Wed, May 18, 2016 at 4:26 PM, Johannes Totz wrote: > 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. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"