whatever happened to yum + btrfs snapshotting?

[Chris Murphy]

On Tue, Feb 17, 2015 at 2:40 PM, Matěj Cepl <mcepl at cepl.eu> wrote:
> On 2015-02-17, 13:17 GMT, Josh Boyer wrote:
>> Now, it is possible to do this in dnf (either with btrfs or with dm
>> snapshots) but I'm not aware of anyone working on it.  Fedora has the
>> Snapper tool available in the repos, which could do snapshotting
>> outside of dnf as well.
>
> Yeah, just that I was told by people who should know that
> snapper was mainly developed by SUSE people so it is quite
> leaning towards BTRFS. Support of DM-thinp snapshots is there,
> but its quality is really not perfect.

Getting thin pool and volumes configured correctly for the many
snapshots that snapper produces is non-obvious and non-trivial. If you
don't do that correctly from the start, and near as I can tell the
installer doesn't configure it for snapshots, even a handful of
snapshots and writing into them will blow up the entire thin pool and
all LV's on it. There's no hand holding and it's not fail safe.

There are some btrfs multiple device gotchas (with device failures,
removal and replace) that are equally non-obvious and non-trivial. But
it's a neck deep swimming pool vs being thrown into the LVM thinp
ocean with giant waves. Btrfs snapshots are deceptively fast and safe.
Many snapshots or snapshots involving large files, can easily result
in significant underestimates of how much free space remains due to
the passive deduplication they imply. And that turns into logistical
problems for backing up and restoring, even with btrfs send/receive,
that are non-obvious and non-trivial.

Many snapshots also confuses the installer, for example:
https://bugzilla.redhat.com/show_bug.cgi?id=1185117
And that's with less than a day of life for a new openSUSE default
installation. Anyway, snapshot buyers beware!

I feel any future discussion of Btrfs by default needs an exception to
the usual way of doing changes: change is proposed and implemented
weeks before a branch. Instead, Btrfs should get months of Rawhide
testing before branch, by becoming default in Rawhide only sooner than
later. And this can explicitly acknowledge it being a non-committing
change for Fedora 23. This is less abrupt of a change and more fail
safe.

-- 
Chris Murphy