Unknown mailing list, 1.

LVM Snapshot Merging

Submitted by Jeremy
on August 9, 2008 - 11:02am

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
Subject: [ANNOUNCE] beta version of LVM snapshot merging
Date: Aug 4, 12: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

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

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

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

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

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

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

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

Wonderful what gets merged into this surprising kernel.

That's just SO ...

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

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

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

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?

Anonymous (not verified)
on
August 10, 2008 - 11:49am

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.

?

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

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

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

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

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

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

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

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

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

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,

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

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

Administrators

Anonymous (not verified)
on
August 10, 2008 - 11:50am

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

Nice troll, but...

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

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

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

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

RPM has package rollbacks,

Anonymous (not verified)
on
August 21, 2008 - 9:53am

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!

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

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

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

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

Considering ...

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

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

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

Linux pee on FreeBSD's wireless tools, thankyouverymuch

BTW, which nutter decided to

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

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

Decided

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

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

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

- 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

Anonymous (not verified)
on
August 13, 2008 - 11:14pm

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

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

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

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

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

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

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

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

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

Anonymous (not verified)
on
August 12, 2008 - 9:21am

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

on
October 14, 2008 - 11:46am

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

Only use Solaris for ZFS /

on
May 3, 2009 - 10:56am

Only use Solaris for ZFS / Snapshot... Shall give this a go.

linus vs. windwos

Diyetler (not verified)
on
July 8, 2010 - 3:37pm

Always linux of course.

Comment viewing options

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