1 |
Am Sun, 11 May 2014 23:24:34 +0200 |
2 |
schrieb "Stefan G. Weichinger" <lists@×××××.at>: |
3 |
|
4 |
[...] |
5 |
> ... but it is really nice-to-have the option to snapshot your root-fs, |
6 |
> do-something-to-it (emerge unstable stuff, delete the wrong files, you |
7 |
> name it ...), and if you don't like it you simply boot using your |
8 |
> snapshot ... that is actually really helpful and also rather easy once |
9 |
> you get your head wrapped around the concepts and the few steps |
10 |
> necessary (and it's quick: the snapshot is done in a blink ...) |
11 |
|
12 |
In a presentation by Donny Berkholz at Fosdem this year [0], he mentioned the |
13 |
distro CoreOS, and that they can do atomic updates. I haven't looked it up in |
14 |
detail, but they're website says that they use a dual-root scheme where the |
15 |
update is performed in a second root, which is made the real root after |
16 |
rebooting or after a kexec [1]. It seems to me that this could be made simpler |
17 |
and easier with btrfs snapshots. |
18 |
|
19 |
> As far as I researched btrfs seems to be quite reliable in a not too |
20 |
> complex (read: multi devices) setup ... and backups never hurt anyway. |
21 |
|
22 |
Of course, for me one of *the* big features was the capability to automatically |
23 |
fix corrupted data (the self-healing features of btrfs). This is only possible |
24 |
when you have redundancy across multiple devices. (I'm running a scrub right |
25 |
now.) |
26 |
|
27 |
But even with a single device, you can at least *detect* corruption, I just |
28 |
want to also be able to have it automatically *corrected*. |
29 |
|
30 |
> As I do backups all the time I feel quite confident to test my setups |
31 |
> for the next few days and maybe even completely overhaul my desktop setup. |
32 |
|
33 |
Ditto :) . As risky as it is, this was also a "test" of my backup, in the |
34 |
sense that, while I knew the backups looked okay by manual inspection, I |
35 |
hadn't actually restored from backup yet. Obviously, it worked :) . |
36 |
|
37 |
> -> 2x 1TB HDDs plus 1x 256GB SSD (plus the one older 80GB SSD for tests |
38 |
> right now) ... with LVM and stuff (remember my hassles last week with |
39 |
> the LVMs not activated??) ... I could run one btrfs-pool on the 2 HDDs |
40 |
> and one on the SSD and cut all of my various filesystems out of that. |
41 |
> |
42 |
> Would mixing hdds and the ssd into one pool make sense? I think, no ... ? |
43 |
|
44 |
I suspect something like bcache would work (except I remember reading that |
45 |
btrfs does not work with it yet). |
46 |
|
47 |
> -- |
48 |
> |
49 |
> I will also test running VMs on btrfs-subvolumes and doing snapshots: |
50 |
> |
51 |
> snapshot the underlying subvolume, apply some changes within the VM and |
52 |
> then rollback to the snapshot. |
53 |
> |
54 |
> This would remove LVM-snapshotting out of the way ... etc etc |
55 |
> |
56 |
> As mentioned before, looking forward ... and curious! |
57 |
|
58 |
I'm glad I motivated some people to try btrfs themselves :) . |
59 |
|
60 |
[0] https://www.youtube.com/watch?v=egjcVGKwnrw |
61 |
[1] http://coreos.com/using-coreos/updates/ (section "technical details") |
62 |
-- |
63 |
Marc Joliet |
64 |
-- |
65 |
"People who think they know everything really annoy those of us who know we |
66 |
don't" - Bjarne Stroustrup |