On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote: > > 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. Note that this situation is perfectly handled by Offline Updates. After reboot, there aren't collateral changes to filesystem, only upgrade-related ones. So if there's a need for revert, the previous state is clearly defined. -- Tomasz Torcz There exists no separation between gods and men: xmpp: zdzichubg@xxxxxxxxx one blends softly casual into the other.
Attachment:
pgpgpU4l5RsBc.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
