On Tue, Feb 17, 2015 at 2:40 PM, Matěj Cepl <mcepl@xxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
