Re: State of unionfs?
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-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: State of unionfs?
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-unsubscr...@freebsd.org"
State of unionfs?
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 -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
