[libvirt] [PATCH] storage: Document wiping formatted volume types
mkletzan at redhat.com
Mon Aug 1 16:11:58 UTC 2016
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
>> 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
>> 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 at redhat.com>
>> 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.
>> * Returns 0 on success, or -1 on error
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the libvir-list