On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
On Jan 24, 2014, at 11:19 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> On Fri, 24 Jan 2014 09:41:13 -0800
> Adam Williamson <awilliam(a)redhat.com> 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(a)chrome.pl one blends softly casual into the other.