Date: Fri, 14 Jun 2013 17:36:05 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Cc: Devin Teske <dteske@freebsd.org> Subject: ZFS Union Message-ID: <13CA24D6AB415D428143D44749F57D7201F81804@ltcfiswmsgmb21>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F81804>