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
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. ---
> 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 -- 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
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 -- 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
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
--
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
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. ---
> 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 -- 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