On Jan 24, 2014, at 11:19 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Fri, 24 Jan 2014 09:41:13 -0800 > Adam Williamson <awilliam@xxxxxxxxxx> wrote: > >> AIUI there is/was a long-term plan to integrate this as core >> functionality using btrfs snapshots - in fact that was one of the >> major attractions of the idea of switching to btrfs-by-default in the >> first place. I believe those involved didn't think the LVM-based >> implementation was clean/robust enough to use by default, but a >> btrfs-based implementation would be. Do correct me if I'm wrong. > > I don't think snapshots are a partcularly good solution, unless there's > some way to only roll back the rpm/yum transaction without also rolling > back unrelated changes. If there is a directory that contains update and non-update related file changes, that's a problem. If there's segmentation, then this can be done. Clearly /home needs to be separate (it's OK to take a snapshot but just don't use it by default in a rollback) or we lose changes in /home in a rollback from the time of the snapshot to the time of the decision to rollback. Another possible case it's /etc/ where the either a package or the user could make changes during the update. Btrfs allows per file snapshots with cp --reflink so there might be a way to carve the snapshot with a scalpel but I prefer doing it with subvolume granularity. Plus that granularity translates to LVM. Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
