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)

[Rich Freeman <r-plug@thefreemanclan.net>]

On Sun, Apr 24, 2016 at 8:42 PM, Keith C. Perry
<kperry@daotechnologies.com> wrote:
> I understand what a silent corruption is however you have to make a fair comparison.  If cosmic rays can flip bits in hardware or software that goes undetected then all bets are off and you're going to have undetected data corruption no matter how your data is stored.
>
> Storage mechanisms are going to use reliable methods to correct or at least detect bad data but there is still a chance that the n+1 plan is defeated by the n+2 event.  In my experience, its just not that "easy".  Which is to say, it is rare those cosmic rays or random events silently flip a bit and human inspection is the only thing that reveals a problem.

The whole point of zfs/btrfs is that they DO detect these kinds of
corruptions, and they automatically use the redundant copy of the
data.  Sure, if the same block in n+2 drives gets hit by a cosmic ray
then you'll still lose it, but that is MUCH less likely to happen than
a single flip, or two flips of unrelated blocks.  The whole server
could get hit by an asteroid as well.

>
> When you stay within statistical norms, this is just not something you can make a choice of file system on.

There are a lot of people who think that silent corruptions for large
arrays are well within the statistical norms now.

> I don't see why there would be increased concern as storage system get larger.  Densities increases have been slowing in favor of a LVM constructs because there are physical limits to how much data can be stored in standard hard disk form factors.  One of those limiters is going to be how durable the data is.  If we can't reliably retrieve data at a certain density then we will never see those densities.

Of course, but the whole point is that filesystems like zfs/btrfs DO
increase the effectively durability of the data, because they increase
your fault tolerance.

Drives already anticipate a certain rate of bit flips and have
built-in ECC to handle this.  The errors that creep through only
happen when the loss exceeds what the ECC can handle.

>
> So, even though BTRFS and other "modern" COW files might have one type of advantage, practically speaking, all points together might not actually yield a detectable net benefit for this single point.

I don't think Oracle would be putting so much money into these
filesystems if they didn't think they offered a practical advantage.

> Coming back around to containers, I still think you nailed it earlier.  It would have been better to have some choices- every piece of tech has its fans so over time we could see how each ephemeral method worked.  Maybe it would have worked as developers conceived, maybe not.  Maybe in a couple of years we'll be talking about a new method all together.
>
> Here's something I just found...  (well, "pacman -Ss btrfs" pointed me in the right direction)
>
> http://snapper.io/overview.html
>
> Apparently someone figured out how to do snapshot management for LVM, BTRFS and EXT4  :D

Yup - snapper is great, and there is no reason that you couldn't use
LVM snapshots for ephemeral containers if they are writable.  I'm sure
the nspawn maintainers would accept a patch if you asked them about
it.

I'm not sure how well LVM handles a large number of snapshots - with
something like snapper you can end up with quite a few.  Though, to be
fair I try to avoid having too many with btrfs as well as when it goes
to clean up a large number of them at once I've run into bugs.

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