1 |
Jesús Guerrero wrote: |
2 |
> |
3 |
> In my opinion, if we really want to speak about a way to implement that |
4 |
> kind of snapshoting, we should start thinking about providing a better |
5 |
> integration with lvm, from the root. lvm can take care of the snapshots on |
6 |
> a non-expensive way, and it would be relatively easy to implement. However |
7 |
> a lot of stuff would need to be re-documented, starting from the handbook, |
8 |
> and the init system. |
9 |
|
10 |
LVM snapshotting is extremely wasteful - it has no knowledge of the |
11 |
underlying structure of a filesystem. For example, if I moved all the |
12 |
files around on a fairly full ext3 filesystem, an LVM snapshot would |
13 |
consume the full size of the filesystem. However, a filesystem-level |
14 |
solution wouldn't need to store a single byte of data since nothing |
15 |
actually changed. |
16 |
|
17 |
Also - a snapshot restoration obliterates ALL data on the partition that |
18 |
has changed since the snapshot was taken - so unless the essential files |
19 |
are on a separate partition it won't work out well. |
20 |
|
21 |
LVM snapshots really seem to be a solution to atomic backups - if you |
22 |
unmount, snapshot, and remount a filesystem then you can run a |
23 |
self-consistent backup off of the snapshot with minimal downtime. The |
24 |
wasted space isn't a big deal since the snapshot would be deleted before |
25 |
it grew too far. |
26 |
|
27 |
Finally - I'm not to eager to try out lvm2 again anytime soon - I lost a |
28 |
ton of data when something glitched and wiped out data across multiple |
29 |
lvm partitions. I know that the error must have been in the lvm layer |
30 |
(not md or the filesystem), because when I fscked and repaired one |
31 |
filesystem, another filesystem instantly became hosed (on a separate lvm |
32 |
partition). Somehow the partitions had gotten scrambled together and |
33 |
the fsck was crossing partition boundaries. Plus, dmesg was dumping all |
34 |
kinds of compliants at the md layer about the lvm device trying to |
35 |
access out-of-range clusters. Googling I found a few other reports of |
36 |
similar behavior - it seems extremely rare, but very nasty. |
37 |
|
38 |
Fortunately the most important stuff on my PC was backed up (good |
39 |
planning), but it was still a pain - I lost tons of DVR recordings since |
40 |
I don't back that up (not worth the cost vs the value of the data). Now |
41 |
I just run ext3 on top of md and I haven't had any problems. |
42 |
|
43 |
You're right that btrfs will definitely help. However, being able to |
44 |
create a personal stage1 tarball at will would certainly also be useful, |
45 |
and it wouldn't actually consume much disk space. |