From owner-freebsd-fs@FreeBSD.ORG Fri Jun 14 17:36:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBD30904; Fri, 14 Jun 2013 17:36:33 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8C39B1F14; Fri, 14 Jun 2013 17:36:33 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r5EHaWlF029633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Jun 2013 12:36:32 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Fri, 14 Jun 2013 12:36:06 -0500 From: "Teske, Devin" To: "freebsd-fs@freebsd.org" Subject: ZFS Union Thread-Topic: ZFS Union Thread-Index: AQHOaSWmuit0fMTVvU+5jica75CJmg== Date: Fri, 14 Jun 2013 17:36:05 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F81804@ltcfiswmsgmb21> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="Windows-1252" Content-ID: <875536F73867504C99A7BE0F16643FDE@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-14_06:2013-06-14,2013-06-14,1970-01-01 signatures=0 Cc: Devin Teske X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:36:33 -0000 Hi List, I had an idea recently that I thought might be worth chasing. I've thought for a long time that it would be really great if I could have = (for the purpose of jails): + ZFS filesystem /vm/master + ZFS filesystem /vm/unit1 + ZFS filesystem /vm/unit2 + ZFS filesystem /vm/unit3 Unlike a ZFS snapshot/clone system, where changes in /vm/master made beyond= the snapshot for which /vm/unit{1,2,3} were cloned-from do not effect /vm/= unit{1,2,3}=85 What if there was a way to layer /vm/unit{1,2,3} in a union manner to be th= e top-layer above /vm/master. I believe that UnionFS isn't of help here specifically because I believe it= to not support the following use-case example: Step 1. touch /vm/master/foo ASIDE: /vm/unit1/foo does not exist prior to Step 1 Step 2. See that now /vm/unit{1,2,3}/foo exists (that was the litmus test for any layering filesystem, now comes the part t= hat I believe UnionFS fails) Step 3. Now, rm /vm/unit1/foo Step 4. See that /vm/master/foo is still there, but /vm/unit1/foo remains g= one Step 5. Counter to Step 4 above, See that /vm/unit2/foo and /vm/unit3/foo s= till exist In other words=85 the filesystem should be able to keep track of unlinked f= iles as a black-list. Enhancing ZFS to support union is quite sexy, because when you go down the = rabbit hole of Steps 3-5 above, you realize you may want to (as an administ= rator) "reclaim" files from a lower layer. This could perhaps be tacked ont= o the "zfs" utility (whereas if enhancing UnionFS, a new utility would need= to be born). I would imagine a "zfs reclaim" (hypothetical fictional command) to allow t= he path from lower layers to become visible again, so-long-as a lower-layer= hasn't black-listed it from an even lower-layer. The end-run production use of this would be to allow jails to "inherit" fil= es from a lower layer but unlike a snapshot system, continue to inherit per= petually in realtime. Going into a lower layer and making a change would im= mediately percolate that change to all the jails layered on top. It would also mean nice lean deltas. Layering "/foo" on top of "/" would be= a quick and dirty way of cloning your base system into a new jail where al= l the writes go off to that directory (something existing UnionFS technolog= ies already do) and -- something not done by existing UnionFS technologies = -- unlinked files will not appear (giving the idea that, while chroot'd or = jail'd into that directory, you have more control over your universe becaus= e you "rm" a file and it goes away; but of course [hypothetically] an admin= istrator in parent host to the jail can "reclaim" it for you from a lower l= ayer if you want him/her to do-so). Thoughts? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.