From: Kai Krakow <hurikhan77+btrfs@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: revert to static snapshot on reboot
Date: Mon, 09 Jan 2012 19:43:35 +0100 [thread overview]
Message-ID: <k3prt8-n92.ln1@hurikhan.ath.cx> (raw)
In-Reply-To: 20120109064304.18411.qmail@otpproductions.com
Hello!
btrfs@spiritvideo.com <btrfs@spiritvideo.com> schrieb:
> The plan that occurs to me is to make a snapshot of the system in the
> state that I want to always boot. Then, I would rewrite the init
> script in the initrd to (a) delete any old tmp copy of the snapshot;
> (b) copy the static snapshot to a tmp copy; (c) mount the tmp copy.
I'd suggest to create a snapshot during initrd phase, then switch to that
snapshot as the root. Before creating the new snapshot, first delete all old
snapshots still there... Something like:
# sda1 = btrfs
mkdir -p /btrfs-prepare
mount /dev/sda1 /btrfs-prepare -o $REAL_ROOT_FLAGS,...
for snapshot in /btrfs-prepare/snapshots/*; do
btrfs sub del "$snapshot"
done
snapshot="snapshots/root-$(date +%s)"
# original-root has to be a subvolume
btrfs sub snap /btrfs-prepare/original-root /btrfs-prepare/"$snapshot"
REAL_ROOT="$snapshot"
sync
umount /btrfs-prepare
# now let the rest of the initrd switch to the real root
# depending on your initrd system REAL_ROOT needs to be named
# differently: it should result in mount options like
# -o subvol=snapshots/root-123456789,...
This should be much faster than copying stuff around. I'm not sure how btrfs
behaves when unmounting during the btrfs-cleaner deleting snapshots. It may
become instable over time. I'm sure the btrfs gurus here can comment on
this. I used a timestamp on the snapshot names so no naming conflicts occur
during snapshot deletion and creation. I figured that if deleting and
recreating the same snapshot name may confuse btrfs after unexpected reboots
while the btrfs-cleaner was still running.
The above script expects your btrfs layout to be something like that:
$ ls -al /
./
original-root/ # system installation goes here (subvolume)
snapshots/ # normal empty directory
# nothing more
This way you can also use an alternate initrd which does no snapshotting to
upgrade or reconfigure the system. Or you just chroot into the original root
and update that.
HTH
Kai
next prev parent reply other threads:[~2012-01-09 18:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 6:43 revert to static snapshot on reboot btrfs
2012-01-09 9:51 ` Hugo Mills
2012-01-09 15:21 ` Niels de Carpentier
2012-01-12 21:38 ` Hugo Mills
2012-01-12 22:01 ` Niels de Carpentier
2012-01-09 18:43 ` Kai Krakow [this message]
2012-01-11 3:42 ` Anand Jain
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=k3prt8-n92.ln1@hurikhan.ath.cx \
--to=hurikhan77+btrfs@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.