Weekly Edition
Return to the Kernel page
| |||||||||||||
Snapshot merge for the device mapper
Last week, LWN looked at the use
of Btrfs snapshots to help system administrators recover from
problematic upgrades. Btrfs is not the only snapshot mechanism in the
kernel, though; the device mapper layer has had this capability for some
time. What is missing from DM is the ability to restore the "origin"
(main) device to an earlier state if need be. So the device mapper, in its
current form, cannot be used to roll back an unfortunate upgrade without
taking the system down and copying data.
That situation could change soon, possibly as early as 2.6.33. Mike Snitzer has posted patches for a snapshot-merge target for DM. This target, simply, merges a snapshot back to the origin device, restoring the state of that device to what it was when the snapshot was taken. So a system administrator could snapshot the device immediately prior to an upgrade, then get back to the pre-upgrade state if things do not go well. One nice feature is that merging a snapshot preserves the state of all other snapshots on the device. So our system administrator could take another snapshot after the failed upgrade, before returning to the previous state. That post-upgrade snapshot would continue to exist, allowing the cherry-picking of any files with changes that should persist after the system as a whole is rolled back. DM maintainer Alasdair Kergon has told your editor that he'll be reviewing this code shortly, and that it may find its way into linux-next in the near future. (Log in to post comments)
Snapshot merge for the device mapper Posted Nov 26, 2009 3:18 UTC (Thu) by intgr (subscriber, #39733) [Link]
So using the broken upgrade example... How does DM tell the file system that "your underlying block device has been changed arbitrarily, please discard everything you know"?
Snapshot merge for the device mapper Posted Nov 26, 2009 4:33 UTC (Thu) by msnitzer (subscriber, #57232) [Link]
DM does not change the block device out from underneath a mounted filesystem. The filesystem (and processes that are using it) would not be able to reliably cope with such an abrupt change to its underlying block device.
The user must decide to merge a snapshot. Once that decision is made the user will initiate the merge using lvm2's lvconvert --merge $VG/$LV
But the actual merge cannot start until both the snapshot that will be merged and its origin device are closed.
So if either the snapshot or origin device are still open (e.g. the filesystem ontop is still mounted) the merge is deferred until the origin LV is next activated.
Snapshot merge for the device mapper Posted Nov 26, 2009 6:10 UTC (Thu) by intgr (subscriber, #39733) [Link]
Well the article suggests that the new feature can "be used to roll back an
unfortunate upgrade without taking the system down"
But needing to unmount the root file system seems pretty much like "taking
Snapshot merge for the device mapper Posted Nov 26, 2009 12:10 UTC (Thu) by nye (guest, #51576) [Link]
That's a fairly major improvement in convenience though. I for one would welcome this very warmly after my LVM escapades a couple of weeks ago.
Snapshot merge for the device mapper Posted Dec 2, 2009 17:29 UTC (Wed) by sethml (subscriber, #8471) [Link] I think the ideal behaviour would be if you could swap a snapshot with the HEAD state of the partition, effective on the next unmount-mount cycle. Then restoring the system to a snapshot state would consist of swapping that snapshot into place and rebooting. You'd still have the borked former HEAD state of the system in a snapshot, which you could delete at will. You're not likely to get more convenient than that.
Snapshot merge for the device mapper Posted Feb 25, 2010 15:28 UTC (Thu) by budee (guest, #63877) [Link]
According to ftp://sources.redhat.com/pub/lvm2/WHATS_NEW you must have lvm version at least 2.02.58 to use --merge.
|
|||||||||||||