Re: [PATCH] storage: Document wiping formatted volume types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 01, 2016 at 11:40:11AM -0400, John Ferlan wrote:


On 08/01/2016 09:13 AM, Martin Kletzander wrote:
When wiping a volume we just rewrite all the data of the volume, not
only the content.  Since format gets overriden, we need to recreate the

overridden

volume.  However we can't do that for every possible format there.  And

s/ there. And/. Since

since it was only coded for the ploop volume type, let's document what

s/since/

might be the consequences instead of forbidding it for every other
format out there.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868771

Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
---
 src/libvirt-storage.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c
index cebe02fdda66..2be95a5adcaf 100644
--- a/src/libvirt-storage.c
+++ b/src/libvirt-storage.c
@@ -1732,6 +1732,12 @@ virStorageVolDelete(virStorageVolPtr vol,
  * journaled, log structured, copy-on-write, versioned, and
  * network file systems are known to be problematic.
  *
+ * NB the data includes the format (and possibly size information), so
+ * non-raw images might become raw with different size from libvirt's

Wouldn't this format and size difference be true for other things as well?
IOW: The 'libvirt's POV' seems odd in this context.  You would also need
to expand POV...

+ * POV.  Due to the fact that not all information for re-creating the
+ * volume can be kept for every volume type, the volume might be kept
+ * in that state and not re-created.
+ *

This part implies "it's too hard to re-create" every known format type
and "original" size option.

Not all storage backends


Here's my suggestion how this could look:

* Ensure data previously on a volume is not accessible to future reads.
*
* The data to be wiped may include the format and possibly size information,
* so non-raw images might become raw with a different size. It is storage
* backend dependent whether the format and size information is regenerated
* once the initial volume wipe is completed.
*
* Depending on the actual volume representation, this call may not
* overwrite the physical location of the volume. For instance, files
* stored journaled, log structured, copy-on-write, versioned, and
* network file systems are known to be problematic.


Yeah, much better.  Will send a v2.


John

  * Returns 0 on success, or -1 on error
  */
 int

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]