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. John > * Returns 0 on success, or -1 on error > */ > int > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list