revert to static snapshot on reboot

revert to static snapshot on reboot

[btrfs]

Hi all --

I just installed my first btrfs-based linux tonight, and I must say it
gives me a very warm feeling!  Congratulations on all your hard work
and your fine product.

I administer laptops for a small school, and we want to implement what
Deep Freeze (http://www.faronics.com/enterprise/deep-freeze) does for
Windows -- no matter what a student does after they log in, when they
reboot it is all forgotten and the computer has returned to a standard
state.

I would think this would be a FAQ, but I have searched the web and
mailing list for the past couple of hours.

Of course it's easy to mount a snapshot, but then if students make
changes the snapshot changes.

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.

That's a little harder than I was hoping to work -- is there an easier
way to get this functionality?

I have a small ext4 boot partition containing grub, vmlinuz and
initramfs.  Everything else is in a big btrfs root partition.  I am
running Fedora 14, with Fedora-patched linux 2.6.35.  I could upgrade
if necessary.

Thanks,
Bob
--
I blog about my work at the school at SmallSchoolIT.wordpress.com

Re: revert to static snapshot on reboot

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

On Sun, Jan 08, 2012 at 10:43:04PM -0800, btrfs@spiritvideo.com wrote:
> Hi all --
> 
> I just installed my first btrfs-based linux tonight, and I must say it
> gives me a very warm feeling!  Congratulations on all your hard work
> and your fine product.
> 
> I administer laptops for a small school, and we want to implement what
> Deep Freeze (http://www.faronics.com/enterprise/deep-freeze) does for
> Windows -- no matter what a student does after they log in, when they
> reboot it is all forgotten and the computer has returned to a standard
> state.
> 
> I would think this would be a FAQ, but I have searched the web and
> mailing list for the past couple of hours.
> 
> Of course it's easy to mount a snapshot, but then if students make
> changes the snapshot changes.
> 
> 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.
> 
> That's a little harder than I was hoping to work -- is there an easier
> way to get this functionality?

   I think you've got the right approach there. I can't immediately
see anything simpler.

   The other way of doing it I can think of, without using btrfs
snapshots, might be to mount / read-only, and then mount a disposable
writable layer on top of it with some union filesystem.

> I have a small ext4 boot partition containing grub, vmlinuz and
> initramfs.  Everything else is in a big btrfs root partition.  I am
> running Fedora 14, with Fedora-patched linux 2.6.35.  I could upgrade
> if necessary.

   Yes, do upgrade. Really, really do upgrade. 2.6.35 is nearly 18
months old, and there are many serious bugs that have been fixed in
btrfs since then. For btrfs, you should be running the latest release
kernel (3.2 currently) at the *minimum*. Preferably, you should be
running the (later-series) -rc kernels; I'd avoid -rc1 or -rc2, but by
-rc3 or so it's usually stabilised to the point that it's usable.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
       --- He's playing Schubert.  I think Schubert is losing. ---       

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: revert to static snapshot on reboot

[Niels de Carpentier]

> 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.
>
> That's a little harder than I was hoping to work -- is there an easier
> way to get this functionality?

I would just create a filesystem with the static content, and on boot do:

mount fs
delete snapshots
create snapshot
unmount fs and mount snapshot.

I'm not sure if you can snapshot a snapshot, otherwise you could start
with a snapshot as well. (Just be sure not to delete it)

Niels

Re: revert to static snapshot on reboot

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Mon, Jan 09, 2012 at 04:21:31PM +0100, Niels de Carpentier wrote:
> > 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.
> >
> > That's a little harder than I was hoping to work -- is there an easier
> > way to get this functionality?
> 
> I would just create a filesystem with the static content, and on boot do:
> 
> mount fs
> delete snapshots
> create snapshot
> unmount fs and mount snapshot.
> 
> I'm not sure if you can snapshot a snapshot, otherwise you could start
> with a snapshot as well. (Just be sure not to delete it)

   Yes, you can make snapshots of snapshots. A btrfs snapshot is a
first-class citizen -- there's no real distinction between the
original subvolume and a snapshot of it.

   Hugo

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
         --- 2 + 2 = 5,  for sufficiently large values of 2. ---         

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: revert to static snapshot on reboot

[Niels de Carpentier]

> On Mon, Jan 09, 2012 at 04:21:31PM +0100, Niels de Carpentier wrote:
>> > 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.
>> >
>> > That's a little harder than I was hoping to work -- is there an easier
>> > way to get this functionality?
>>
>> I would just create a filesystem with the static content, and on boot
>> do:
>>
>> mount fs
>> delete snapshots
>> create snapshot
>> unmount fs and mount snapshot.
>>
>> I'm not sure if you can snapshot a snapshot, otherwise you could start
>> with a snapshot as well. (Just be sure not to delete it)
>
>    Yes, you can make snapshots of snapshots. A btrfs snapshot is a
> first-class citizen -- there's no real distinction between the
> original subvolume and a snapshot of it.

Good! That makes the op's case real simple. No need to copy any data, just
snapshot and mount.

Niels

Re: revert to static snapshot on reboot

[Kai Krakow]

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

Re: revert to static snapshot on reboot

[Anand Jain]

  Upcoming btrfs autosnap feature might help your problem-solution.
  But the main part in your case which is to replace the root
  with its snapshot is something beyond the scope of autosnap
  project.

  What is being developed is a set of btrfs-prog sub-command to
  create and manage snapshots with a rule-set. Code is under
  development, if you would like to test and provide feedback
  I can send you a copy this week.

  OR if you want to just know the new feature relevant to you
  its as below (not a complete features list though).

  - Create snapshot automatically based on
     - AD-hoc (package-installation/boot ..etc)
       
     cli eg:
     # btrfs autosnap enable <tag> <retain-policy> <subvol>

     and the cli that a init or package script should call is
     # btrfs autosnap now -t <tag> /btrfs
     which will create a snapshot and reviews its retention policy.

   retention policy can be based on count, based on FS % full, OR
   manually maintained snapshots.


  If you have any feedback pls let me know.

thanks, Anand

On Monday 09,January,2012 02:43 PM, btrfs@spiritvideo.com wrote:
> Hi all --
>
> I just installed my first btrfs-based linux tonight, and I must say it
> gives me a very warm feeling!  Congratulations on all your hard work
> and your fine product.
>
> I administer laptops for a small school, and we want to implement what
> Deep Freeze (http://www.faronics.com/enterprise/deep-freeze) does for
> Windows -- no matter what a student does after they log in, when they
> reboot it is all forgotten and the computer has returned to a standard
> state.
>
> I would think this would be a FAQ, but I have searched the web and
> mailing list for the past couple of hours.
>
> Of course it's easy to mount a snapshot, but then if students make
> changes the snapshot changes.
>
> 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.
>
> That's a little harder than I was hoping to work -- is there an easier
> way to get this functionality?
>
> I have a small ext4 boot partition containing grub, vmlinuz and
> initramfs.  Everything else is in a big btrfs root partition.  I am
> running Fedora 14, with Fedora-patched linux 2.6.35.  I could upgrade
> if necessary.
>
> Thanks,
> Bob
> --
> I blog about my work at the school at SmallSchoolIT.wordpress.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html