Rich Freeman on 21 Apr 2016 14:40:49 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] [plug-announce] TOMORROW - Tue, Apr 19, 2016: PLUG North - "Linux Containers" by Jason Plum and Rich Freeman (*6:30 pm* at CoreDial in Blue Bell)

On Thu, Apr 21, 2016 at 3:56 PM, Keith C. Perry
<> wrote:
> Not sure what you mean by "revert to snapshot".  My read of this is that when you launch and ephemeral container that is the actually snapshot created.  Similar to creating and running off of a VM clone.  When you are done (i.e. shut down the container) any changes you made against the container are gone thus there are actually no changes written into the container path.  If you were to launch the container again as ephemeral it would have to redo any work you performed previously.

Are LVM snapshots writable?  Once upon a time at least you could make
a read-only snapshot of a filesystem, but you couldn't modify the
snapshot, and you couldn't return the logical volume to the state of
the snapshot without copying the snapshot to someplace else and then

You're right that nspawn is probably leaving the original alone and
just launching a container in the snapshot and deleting this when it
is done, but that requires a writeable snapshot.

> Well yea but that is like saying you can only do Linux stuff if run Linux  :)  To clarify, when I said agnostic I was referring to the LVM snapshot facility- that is what is agnostic since you can create snapshots for any file system.

Sure, but there are downsides to running something like btrfs on LVM.
LVM is also not feature-complete with btrfs even with regard to
snapshotting.  I can reflink a single file in btrfs but there is no
practical way to alias the cp command to create COW snapshots with

> "I imagine it would be pretty painful to use multi-device support on btrfs in conjunction with LVM."
> LVM now include md's functionality (it does the heavy lifting under the hood) and the current [Redhat] recommendation as I read it, is to use LVM for everything- there is no functional reason to use md anymore.  So, with LVM you could easily create and manage a multi-device system with whatever fs you wanted on top of it and still be able to snapshot.

Sure, but if you do it that way then you lose btrfs's ability to cope
with silent corruptions and so on.  You also get the raid hole back
when striping, and some other optimizations that are possible when the
filesystem handles the device management.  I imagine that LVM would
also not cope as well with striping across devices of mixed sizes and
so on.

Back when both btrfs and zfs were created there was an intentional
decision to not take advantage of the existing mdadm/lvm capabilities
(or their equivalents on other OSes), because it was felt that it was
impossible to deliver the same feature set without violating the
existing layers.

I'm not suggesting that btrfs really is production-ready.  I'm just
saying that you don't get the same functionality by building on LVM,
and anybody using btrfs actually loses functionality if they put it on
top of LVM.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --