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
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
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
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
Wonderful what gets merged into this surprising kernel.
That's just SO ...
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
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?
Yeah, backup is a totally new and awesome thing. Nobody has ever done it before. Oh wait ...
So let the package manager suck and fix the problem with new LVM features?
Touchy zealot.
?
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 ...
No. I generally just do an incremental one, when I feel the need ...
I think you just defined "arrogance" for me. No need, I do have a dictionary.
I think you just defined
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
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
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,
If I understand correctly, You talking about "Administrator" problem, which You want to be fixed instead.
Administrators
Yes, we all know how easy it is to fix those.
Nice troll, but...
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
Sounds like Linux users will soon be able to rollback failed upgrades as well, if they use LVM or btrfs.
RPM has package rollbacks,
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!
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
And Linux has had features for years that FreeBSD didn't have, so what?
Considering ...
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
Linux pee on FreeBSD's wireless tools, thankyouverymuch
BTW, which nutter decided to
BTW, which nutter decided to pollute ifconfig with wireless control on the BSD's?
Decided
The same "nutter" that figured wireless network interfaces were network interfaces too, I suppose.
- And ifconfig should of
- 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
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
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
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
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
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
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
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 /
Only use Solaris for ZFS / Snapshot... Shall give this a go.
linus vs. windwos
Always linux of course.