From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: How does Suse do live filesystem revert with btrfs?
Date: Mon, 5 May 2014 02:39:57 +0000 (UTC) [thread overview]
Message-ID: <pan$1e4dd$1456e7b9$312797ca$4849ce65@cox.net> (raw)
In-Reply-To: 20140504005257.GF9061@merlins.org
Marc MERLIN posted on Sat, 03 May 2014 17:52:57 -0700 as excerpted:
> (more questions I'm asking myself while writing my talk slides)
>
> I know Suse uses btrfs to roll back filesystem changes.
>
> So I understand how you can take a snapshot before making a change, but
> not how you revert to that snapshot without rebooting or using rsync,
>
> How do you do a pivot-root like mountpoint swap to an older snapshot,
> especially if you have filehandles opened on the current snapshot?
>
> Is that what Suse manages, or are they doing something simpler?
While I don't have any OpenSuSE specific knowledge on this, I strongly
suspect their solution is more along the select-the-root-snapshot-to-roll-
back-to-from-the-initramfs/initrd line.
Consider, they do the snapshot, then the upgrade. In-use files won't be
entirely removed and the upgrade actually activated for them until a
reboot or at least an application restart[1] for all those running apps
in ordered to free their in-use files, anyway. At that point, if the
user finds something broke, they've just rebooted[1], so rebooting[1] to
select the pre-upgrade rootfs snapshot won't be too big a deal, since
they've already disrupted the normal high level session and have just
attempted a reload in ordered to discover the breakage, in the first
place.
IOW, for the rootfs and main system, anyway, the rollback technology is a
great step up from not having that snapshot to rollback to in the first
place, but it's /not/ /magic/; if a rollback is needed, they almost
certainly will need to reboot[1] and from there select the rootfs
snapshot to rollback to, in ordered to mount it and accomplish that
rollback.
---
[1] Reboot: Or possibly dipped to single user mode, and/or to the
initramfs, which they'd need to reload and switch-root into for the
purpose, but systemd is doing just that sort of thing these days in
ordered to properly unmount rootfs after upgrades before shutdown as it's
a step safer than the old style remount read-only, and implementing a
snapshot selector and remount of the rootfs in that initr* instead of
dropping all the way to a full reboot is only a small step from there.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
prev parent reply other threads:[~2014-05-06 19:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-04 0:52 How does Suse do live filesystem revert with btrfs? Marc MERLIN
2014-05-04 23:26 ` Marc MERLIN
2014-05-05 0:36 ` Hugo Mills
2014-05-05 5:04 ` Marc MERLIN
2014-05-06 16:26 ` Duncan
2014-05-07 8:56 ` Marc MERLIN
2014-05-07 11:35 ` Duncan
2014-05-07 11:39 ` Marc MERLIN
2014-05-07 18:33 ` Goffredo Baroncelli
2014-05-05 3:23 ` Chris Murphy
2014-05-05 6:50 ` Marc MERLIN
2014-05-05 2:39 ` Duncan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$1e4dd$1456e7b9$312797ca$4849ce65@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).