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)

["Keith C. Perry" <kperry@daotechnologies.com>]

LVM snapshots are writeable...

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/snapshot_volumes.html

Under "There are several uses for the snapshot feature"

"Because the snapshot is read/write, you can test applications against production data by taking a snapshot and running tests against the snapshot, leaving the real data untouched."


"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
LVM."

Ahh, ok if "reflink" means individual file recover, then I see that point.

"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."

Well this is interesting...  I've never heard of the "raid hole" but more importantly one of the ideas behind using LVM is that file systems are poor at device management.  If they were, they would become bloated with code to do things that have little to do with implementing a good file system.  It's possible that BTRFS and ZFS go against that paradigm but that doesn't make much sense to me, especially in the context of "do one thing and do it well".  However, I suspect for those there is plenty of use cases for both approaches at this point.

"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."

Is that really true though?  I now can see based on what you said above why someone might feel that BTRFS (or ZFS) includes enough utility to do good volume management but as far as file system features, excluding RAID functionality, how would BTRFS on top of say /dev/sdb be "better" than BTRFS on top of /dev/myServer/myData (myServer being the VG and myData being the LV)?  'Could be my ignorance of BTRFS but a device is a device so the fs should not know or even care that it is on an LV.


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Owner, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167 
www.daotechnologies.com

----- Original Message -----
From: "Rich Freeman" <r-plug@thefreemanclan.net>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Thursday, April 21, 2016 5:40:43 PM
Subject: 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
<kperry@daotechnologies.com> 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
back.

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
LVM.

>
> "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.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug