Red Hat Bugzilla – Bug 236168
pvcreate should automatically make a backup of what it overwrites
Last modified: 2013-02-28 23:05:45 EST
RHEL 5.1 clone - some code exists (see bug 174701),
nice to have this in RHEL5 too.
+++ This bug was initially created as a clone of Bug #174701 +++
LVM2 pvcreate should make an automatic backup of the part of
the device that it overwrites, so you can undo it.
(Could add as a generic option in the low-level write function, so other
commands could use it too.)
[split off from bugzilla 168330]
-- Additional comment from email@example.com on 2007-04-11 12:43 EST --
Created an attachment (id=152288)
Here comes a preliminary patch implementing basic pvcreate --undo
functionality. It has a few rough edges yet, like there is no configuration
option to disable pvcreate archive creation (easy to fix) and that
offset/length pairs are written out in host byte order (needs ntohll/htonll
which seem to be missing from libc? needs investigation).
The design is simplistic, it provides new device write primitives suffixed
_backup that take an extra file descriptor argument, which they use to write
out a copy of whatever they are going to overwrite, prepended with offset and
length of the block.
The restore function takes a file that contains several such blocks and writes
them over in their original positions, in reverse order from the file. This
allows for easy backup implementation, where a backup file is created and
opened for writing, its fd is passed to every device write operation and file
is closed. Then, restore takes the opened device and a filename of backup file.
Things like further metadata about the operation are left for higher layers, in
this case pvcreate. Current implementation just uses <archive_dir>/<uuid>.pv as
backup file and --undo on a PV looks for this file which when found is used for
restore. There is room for a more elaborate operation logfile, which may
reference the (simplistic) binary backup files. Any checksumming should be
probably done on that (operation logfile) level as well.
To make it possible for format_text to use the backup-enabled device
operations, i have added device_backup_fd to toolcontext. This may need
different addressing as well, although there is not much room for maneuvering
-- probably either way, all dev_write/dev_set calls that need backup
functionality will have to be modified in a way or other (either replace them
with versions that take toolcontext parameter, or the _backup versions).
I will followup with improved patches either tonight or tomorrow.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
> We have decided with Alasdair to rework this patch differently, for improved
> maintainability and future-proofness. The feature is not critical in any way
> and can be deferred for next update. I will followup with updates when the
> work on this is resumed.
That means it might be done in 5.3 timeframe, or might not (although I'd hope
for the former). Hotspare capabilities get priority over this.
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.