login
Header Space

 
 

LVM Snapshot Merging

August 9, 2008 - 2:02pm
Submitted by Jeremy on August 9, 2008 - 2:02pm.
Linux news

Mikulas Patocka announced new patches introducing snapshot merging for the Linux kernel's logical volume manager. He explained, "snapshot merging allows you to merge snapshot content back into the original device. The most useful use for this feature is the possibility to rollback [the] state of the whole computer after [a] failed package upgrade, [or an] administrator's error". The patches are for the 2.6.26 kernel, with device mapper 1.02.27 and LVM2.2.02.39.

Mikulas noted that there are three types of merges supported, --nameorigin, --namesnapshot, and --onactivate. The default merge method is --nameorigin, which can merge a snapshot into the origin volume, which can be mounted at any time after the merge starts. The --namesnapshot method merges into a snapshot, which can then be mounted. And the --onactive method schedules a merge to happen the next time the volume is activated, such as during a reboot. Mikulas noted, "this implementation of snapshot merging is meant to be stable, report any possible bugs to me."


From: Mikulas Patocka <mpatocka@...>
Subject: [ANNOUNCE] beta version of LVM snapshot merging
Date: Aug 4, 3:24 pm 2008

Hi

I'd like announce beta version of snapshot merging. The patches can be 
downloaded at http://people.redhat.com/mpatocka/patches/ The patches are 
against kernel 2.6.26, device-mapper.1.02.27 and LVM2.2.02.39.

The snapshot merging allows you to merge snapshot content back into the 
original device. The most useful use for this feature is the possibility 
to rollback state of the whole computer after failed package upgrade, 
administrator's error or so.

Merging of a snapshot is initiated with command "lvconvert -M 
vg/lv_snapshot". lvconvert polls for the termination of merging and then 
automatically removes the merging snapshot. If the computer crashes, the 
merging resumes after a crash and background polling is restarted too 
(from lvchange -ay or vgchange -ay command).

While the merging is active, any accesses to the origin device are 
dicrected the snapshot that is being merged. When the merging finishes, 
the origin target is seamlessly reloaded and the merging snapshot is 
dropped. The filesystem can stay mounted during this time.

There are three types of merging:

--nameorigin (default) - the resulting logical volume will have name, 
minor number and UUID of the original origin volume. When this mode is 
used, neither snapshot nor the origin can be mounted when the merging 
starts. (but you can mount the origin immediatelly after you start 
merging, you don't have to wait until it finishes)

--namesnapshot - the resulting logical volume will have name, minor number 
and UUID of the snapshot to be merged. When the merging starts, the 
snapshot can be mounted and the origin cannot be mounted.

--onactivate - marks the snapshot for merge on next activate (when 
lvchange -ay or vgchange -ay changes the state from inactiva to active), 
but doesn't do actual merging. This option is useful if you need to merge 
over a filesystem that cannot be unmounted (for example root) --- use 
lvconvert -M --onactivate and reboot the computer. On next reboot, the 
merge will start and the system will run with root filesystem 
corresponding to the snapshot that is being merged.

You can have multiple snapshots before you start merging, any existing 
snapshots are maintained stable (i.e. new exceptions to them are allocated 
if the merging modifies the origin). The exception is --namesnapshot 
option which requires that you have only one snapshot. While the merging 
is in progress, new ssnapshots cannot be created.
For example:
- take snapshot before system-wide package update
- do update
- now suppose that you don't like the result of the update:
- take another snapshot
- initiate -M --onactivate with the first snapshot
- reboot
- after reboot you are running with root filesystem in the state before 
the update and you can examine the result of the update on the second 
snapshot. If you decide that you like the update anyway, you can merge it 
back again (with reboot).
(don't forget to regenerate lvm on your initramdisk if you are going to 
try this on root filesystem).


This implementation of snapshot merging is meant to be stable, report any 
possible bugs to me.

Mikulas
--


This is fantastic news, I

August 9, 2008 - 6:00pm
Anonymous (not verified)

This is fantastic news, I have been waiting for that since ages, I can finally show to those arrogant Solaris/Mac engineer how Linux is superior!

:-P

August 10, 2008 - 10:38am
Anonymous (not verified)

Meanwhile, Solaris has had this kind of rollback feature for a while. Linux is just catching up now? With non-mainstream patches?

Welcome to yesterday son.

Give it a break. Early on

August 10, 2008 - 1:59pm
Anonymous (not verified)

Give it a break. Early on Linux never had the resources that the big boys had. Now that Linux has gone mainstream, everyone (or people like you) automatically expect it to have every feature of all other OSes combined. Yes, playing catchup in certain areas is what Linux is doing. Someday, it will overtake. Perhaps that's what you are really afraid of? Your Solaris skills becoming obsolete?

Or, perhaps you could take the time to get Solaris to run on my OpenMoko? Better yet, perhaps you and your buddy could run some simulations on a 1024 CPU Altix 4700 with Solaris?

See, there's catchup on both sides of the fence... So please, give it a break...

Evolution

August 9, 2008 - 8:36pm
fabian (not verified)

Wonderful what gets merged into this surprising kernel.

That's just SO ...

August 10, 2008 - 7:41am
Anonymous (not verified)

The most useful use for this feature is the possibility
to rollback state of the whole computer after failed package upgrade [...]

That's just SO Windows. Rather than fixing the the problem itself, they add tools to fix the result of the problem. Great.

Yeah, we wouldn't want the

August 10, 2008 - 7:46am
Anonymous (not verified)

Yeah, we wouldn't want the possibility to save our systems, that's for sissies. Especially not since it COULD BE used as a failed package rollback.

You moron.

Backup?

August 10, 2008 - 2:49pm
Anonymous (not verified)

Yeah, we wouldn't want the possibility to save our systems, that's for sissies.

Yeah, backup is a totally new and awesome thing. Nobody has ever done it before. Oh wait ...

Especially not since it COULD BE used as a failed package rollback.

So let the package manager suck and fix the problem with new LVM features?

You moron.

Touchy zealot.

?

August 10, 2008 - 3:44pm
Anonymous (not verified)

Yeah, backup is a totally new and awesome thing. Nobody has ever done it before. Oh wait ...

So you always follow those instructions that come with old apps that tell you to do a full system backup before installing them?

If you do, GP post was right. If not, you're wrong.

Follow instructions ...

August 10, 2008 - 5:07pm
Anonymous (not verified)

So you always follow those instructions that come with old apps that tell you to do a full system backup before installing them?

No. I generally just do an incremental one, when I feel the need ...

If you do, GP post was right. If not, you're wrong.

I think you just defined "arrogance" for me. No need, I do have a dictionary.

I think you just defined

August 11, 2008 - 7:25am
Anonymous (not verified)

I think you just defined "arrogance" for me. No need, I do have a dictionary.

Pot and kettle.

Just because this feature can be used to recover from (spurious) packaging problems easily and painlessly makes the feature bad?

Give me a break.

No

August 11, 2008 - 9:30am
Anonymous (not verified)

Just because this feature can be used to recover from (spurious) packaging problems easily and painlessly makes the feature bad?

Of course not. However, that was mentioned as one of the main uses for it, if you read the article.

So let the package manager

August 12, 2008 - 3:57pm
Anonymous (not verified)

So let the package manager suck and fix the problem with new LVM features?
What about doing the best job they can with the package manager but being humble enough to acknowledge they make mistakes?

If I understand correctly,

August 10, 2008 - 10:34am
Anonymous (not verified)

If I understand correctly, You talking about "Administrator" problem, which You want to be fixed instead.

Administrators

August 10, 2008 - 2:50pm
Anonymous (not verified)

Yes, we all know how easy it is to fix those.

Nice troll, but...

August 11, 2008 - 8:58am
Jeff Schroeder (not verified)

Apparently you haven't heard of Solaris's "new" package manager:
http://opensolaris.org/os/project/pkg/

It uses zfs snapshots to support rollbacks on failed upgrades.

A package manager that is ATOMIC is nothing by cool. The only similar thing for Linux is conary, but it is really slow.

Sounds like Linux users will

August 11, 2008 - 7:51pm
Anonymous (not verified)

Sounds like Linux users will soon be able to rollback failed upgrades as well, if they use LVM or btrfs.

RPM has package rollbacks,

August 21, 2008 - 12:53pm
Anonymous (not verified)

RPM has package rollbacks, at least on RHEL. Its not enabled by default, but I enable it on some of my critical servers.

Welcome to last year!

August 11, 2008 - 4:59pm
Anonymous (not verified)

UFS2 (on FreeBSD) has had snapshotting for years. This is how it runs an fsck in the background after a crack or improper power-off while booting your system. ZFS has had this since the beginning (along with cloning).

I'm honestly surprised it took this long for Linux to get it. I know the Veritas FS has had this, but really, who wants to spend thousands of dollars for an individual PC...

And Linux has had features

August 12, 2008 - 7:26am
Anonymous (not verified)

And Linux has had features for years that FreeBSD didn't have, so what?

Considering ...

August 12, 2008 - 8:06am
Anonymous (not verified)

Considering the amount of people working on Linux, it /is/ quite surprising it took this long. Now, perhaps they'll follow the BSDs and get good wireless support too, and sane tools to configure them.

Linux pee on FreeBSD's

August 12, 2008 - 10:48pm
Anonymous (not verified)

Linux pee on FreeBSD's wireless tools, thankyouverymuch

BTW, which nutter decided to

August 12, 2008 - 10:54pm
Anonymous (not verified)

BTW, which nutter decided to pollute ifconfig with wireless control on the BSD's?

Decided

August 13, 2008 - 3:12am
Anonymous (not verified)

[...] which nutter decided to pollute ifconfig with wireless control on the BSD's?

The same "nutter" that figured wireless network interfaces were network interfaces too, I suppose.

- And ifconfig should of

August 13, 2008 - 3:38pm
Anonymous (not verified)

- And ifconfig should of course take care of the network part of it, but not be stuffed full of unrelated scanning and other control.

I guess they'll merge the routing part into it next, or start to use it to control bind.

Eh

August 14, 2008 - 2:14am
Anonymous (not verified)

And I guess you have no clue what you're talking about, let alone used BSD for any significant amount of time. Your ignorance is astonishing.

So? Try to tell me WHY you

August 15, 2008 - 9:31am
Anonymous (not verified)

So? Try to tell me WHY you think I have no clue, instead of just spewing crap.

FYI, I have the grand displeasure of managing a FreeBSD server at work.

LVM had snapshotting for years, too

August 12, 2008 - 9:36am
sileNT (not verified)

LVM had snapshotting for years, too.

This news is about merging snapshot back into original - it it possible with UFS2? I couldn't find any documentation confirming such a feature.

Isn't deleting a snapshot

August 12, 2008 - 10:26am
Anonymous (not verified)

Isn't deleting a snapshot the same? Last I remember, deleting a snapshot keeps all the data intact on the main filesystem branch...

no, it isn't

August 12, 2008 - 11:16am
sileNT (not verified)

Deleting a snapshot is deleting a snapshot - it is gone with all changes.

However consider this theoretical example (:

1) You have an important filesystem (i.e., holding lots of important data)
2) You make a snapshot of a volume holding that filesystem
3) you do changes - run your scripts for manipulating this set of data; you are not sure if your scripts work perfectly, and hence - the snapshot

Now what could happen?

a) your scripts failed and you damaged the data: simply remove the snapshot, and start over
b) everything worked perfectly - instead of copying data from the snapshot to the original (if you had gigabytes or terabytes of data, it could take hours), you just "merge" the snapshot in the original volume.
In other words, your snapshot becomes "the original" volume now.

It was too early for me I

August 12, 2008 - 12:21pm
Anonymous (not verified)

It was too early for me I guess.. I really don't know what I was smoking. yea, merging all the snapshot data into your base filesystem with the original frozen files of the snapshot makes sense.

veritas

October 14, 2008 - 2:46pm

I'm honestly surprised it took this long for Linux to get it. I know the Veritas FS has had this, but really, who wants to spend thousands of dollars for an individual PC...

Veritas Storage Foundation Basic is free for use (with limits on it's usage) for about year now. Pretty neat to migrate from old Solaris servers to Linux :)

/mator

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary