Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] {OT} Allow work from home?
Date: Fri, 22 Jan 2016 21:59:28
Message-Id: CAGfcS_mecJz2jPRoFpjiGLCMmFiSb+oMWvyXb9ovUw6VkNOx7A@mail.gmail.com
In Reply to: Re: [gentoo-user] {OT} Allow work from home? by lee
1 On Thu, Jan 21, 2016 at 5:00 PM, lee <lee@××××××××.de> wrote:
2 > Hm, I must be misunderstanding snapshots entirely.
3 >
4
5 Well, in the case of zfs/btrfs you are. Different implementations
6 have different snapshotting features.
7
8 > What happens when you remove a snapshot after you modified the
9 > "original" /and/ the snapshot? You destroy at least one of them, so you
10 > can never get rid of the snapshot in a non-destructive way?
11
12 If you remove a snapshot it goes away. If you remove the original it
13 goes away. There isn't anything strange going on.
14
15 With btrfs I can do this:
16
17 btrfs su create a
18 touch a/file
19 btrfs su snap a b
20 touch b/file2
21 echo "hello" >> a/file
22
23 a now contains file with the text hello in it. b now contains file
24 which is empty and file2 which is empty.
25
26 If I delete a then it disappears. If I delete b then it disappears.
27 They exist completely independently of each other.
28
29 In btrfs the command "btrufs su snap a b" is somewhat equivalent to
30 "cp -a a b" unless you look at what is going on closely. The main
31 difference is that the first command takes almost zero time to
32 execute, and consumes little additional space. This is true even if a
33 is a directory containing a million text files or 10TB of video.
34
35 Snapshots in btrfs just look like directories. They're subvolumes,
36 and only subvolumes can be snapshotted. I imagine that zfs is
37 slightly different, but with the same overall concept.
38
39 > My understanding is that when you make a snapshot, you get a copy that
40 > doesn't change which you can somehow use to make backups.
41
42 You can certainly use snapshots to make backups. The snapshot is
43 already a backup, though stored on the same media.
44
45 > When the
46 > backup is finished, you can remove the snapshot, and the changes that
47 > were made in the meantime are not lost --- unless you decide to throw
48 > them away when removing the snapshot, in which case you get a rollback.
49
50 With btrfs at least there is no way to rollback a snapshot. You can
51 of course just "mv a a.old ; mv b a ; btrfs su del a.old" and now your
52 snapshot has replaced the original copy (aside from any files which
53 happen to be open).
54
55 >
56 > To make things more complicated, I've seen zfs refusing to remove a
57 > snapshot and saying that something is recursive (IIRC), and it didn't
58 > make any sense anymore. So I left everything as it was because I didn't
59 > want to loose data, and a while later, I removed this very same snapshot
60 > without getting issues as before. Weird behaviour makes snapshots
61 > rather scary, so I avoid them now.
62
63 I couldn't tell you what that means. Perhaps you discovered a bug.
64
65 Btrfs should always allow you to remove a subvolume (including one
66 created as a snapshot). I believe they can be removed if they're in
67 use, and the effect is similar to removing a file that is in use.
68
69 > There seems to be some sort of relationship between a snapshot and the
70 > "original" which limits what you can do with a snapshot, like the
71 > snapshot is somehow attached to the "original". At least that makes
72 > some sense to me because no real copy is created when you make a
73 > snapshot. But how do you detach a snapshot from the "original" so that
74 > you could savely modify both?
75 >
76
77 In btrfs there is no relationship between a snapshot and the original
78 subvolume, other than them happening to share the same tree nodes
79 initially. It isn't unlike what happens in git when you create a new
80 branch. You end up with a new reference pointing to the same commit
81 and everything below that is shared between the two branches
82 initially. If you touch one file then most of trees/blobs between the
83 branches are still shared, but the modified blob and all of its parent
84 trees are now separated.
85
86 Btrfs does mark snapshots as snapshots for some reason, but other than
87 a yes/no flag snapshots are the same as any subvolume. They're not
88 linked in any way to the original and there is no straightforward way
89 to tell where a snapshot came from (well, other than either comparing
90 it against all the other subvolumes, ideally looking for shared tree
91 nodes).
92
93 --
94 Rich