* [PATCH] [DRAFT] Binary backups (aka pvcreate --undo, RHBZ#174701)
@ 2009-10-05 21:43 Petr Rockai
2009-10-06 16:10 ` Dave Wysochanski
0 siblings, 1 reply; 2+ messages in thread
From: Petr Rockai @ 2009-10-05 21:43 UTC (permalink / raw)
To: lvm-devel
Hi,
I'm attaching a first draft of the binary backup stuff. There's a lot of code,
roughly in 4 areas:
- export lower levels of the config parsing and writing library code
- code for reading and writing the backup format using the above
- hook into dev_write and dev_set to back up before overwriting
- code for restoring the backups
The format currently looks like this:
offset=123
old="..."
new="..."
<repeat>
where old and new are base64-encoded chunks of data, at most 512-byte each
(something less than 700 bytes in base64).
I'd probably prepend a "version=X" to the start, and maybe a bit of metadata --
the files are stored as pv-<uuid>.bin and lv-<uuid>.bin, but don't themselves
contain any hint as to what they are.
The backup part of the code should be straightforward. The restore is, on the
other hand, quite laborious, as a lot of checking is done on the backup file --
we will refuse to restore a backup if the device has changed since that backup
had been made, to avoid data loss (we may want to add -f to override that
check). There's some extra complexity to deal with the fact that a single
command may overwrite same sector multiple times. I think the current design is
fairly robust in that respect -- more so than a more intelligent (and more
error-prone) implementation squashing the backed-up sectors at backup time
would be.
The current implementation is not 100% efficient (especially on the memory side
of things), but can be improved if this turns out to be a problem.
The code is not completely done/ready, but a preliminary review would be
definitely appreciated. It does come with a test that passes and I think it's
in a fairly good shape correctness-wise, but there are some cleanups that ought
to be done before merging.
Yours,
Petr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binbackup.diff
Type: text/x-diff
Size: 49737 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20091005/a9c4134d/attachment.bin>
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH] [DRAFT] Binary backups (aka pvcreate --undo, RHBZ#174701)
2009-10-05 21:43 [PATCH] [DRAFT] Binary backups (aka pvcreate --undo, RHBZ#174701) Petr Rockai
@ 2009-10-06 16:10 ` Dave Wysochanski
0 siblings, 0 replies; 2+ messages in thread
From: Dave Wysochanski @ 2009-10-06 16:10 UTC (permalink / raw)
To: lvm-devel
One initial comment about "pvcreate --undo".
I'm wondering whether we should start moving recovery options to
separate commands altogether. For instance,
- pv{repair|restore}
This would be analogous to vgcfgrestore. We might also think about
moving the pvcreate restore options (--uuid, --restorefile) to this
new command.
I think eventually we will deprecate pvcreate in favor of
vgcreate/vgextend.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-10-06 16:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-05 21:43 [PATCH] [DRAFT] Binary backups (aka pvcreate --undo, RHBZ#174701) Petr Rockai
2009-10-06 16:10 ` Dave Wysochanski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.