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

[Martin Kletzander]

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 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.

>
>John
>
>>   * Returns 0 on success, or -1 on error
>>   */
>>  int
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160801/9d2276f8/attachment-0001.sig>