[libvirt] [PATCH v2] storage: Attempt to refresh volume after successful wipe volume

[Martin Kletzander]

On Tue, Dec 15, 2015 at 03:03:33PM -0500, John Ferlan wrote:
>https://bugzilla.redhat.com/show_bug.cgi?id=1270709
>
>When a volume wipe is successful, perform a volume refresh afterwards to
>update any volume data that may be used in future volume commands, such as
>volume resize.  For a raw file volume, a wipe could truncate the file and
>a followup volume resize the capacity may fail because the volume target
>allocation isn't updated to reflect the wipe activity.
>
>Since the documentation doesn't mention this side effect of the zero
>algorithm for a raw file volume, update the various documentation to
>describe the results.
>

Oh yes, side effects, we have many of those regarding volume wiping.
For this one, I think you cose the best solution, so even though there
are some other hidden things, at least this is cleaned up a bit now.

ACK

>Signed-off-by: John Ferlan <jferlan at redhat.com>
>---
> v1:
> http://www.redhat.com/archives/libvir-list/2015-December/msg00085.html
>
> Changes since v1:
>   * Use the preferred call format from review
>   * Cause error if refreshVol fails
>   * Add wording to docs regarding zero wipe algorithm and truncating
>     the raw file.
>
> src/libvirt-storage.c        | 9 +++++++--
> src/storage/storage_driver.c | 9 ++++++++-
> tools/virsh.pod              | 5 +++++
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
>diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c
>index 66dd9f0..62bb999 100644
>--- a/src/libvirt-storage.c
>+++ b/src/libvirt-storage.c
>@@ -1725,7 +1725,9 @@ virStorageVolDelete(virStorageVolPtr vol,
>  * @vol: pointer to storage volume
>  * @flags: extra flags; not used yet, so callers should always pass 0
>  *
>- * Ensure data previously on a volume is not accessible to future reads
>+ * Ensure data previously on a volume is not accessible to future reads.
>+ * Use of this function is equivalent to calling virStorageVolWipePattern
>+ * with the VIR_STORAGE_VOL_WIPE_ALG_ZERO for the algorithm.
>  *
>  * Returns 0 on success, or -1 on error
>  */
>@@ -1766,7 +1768,10 @@ virStorageVolWipe(virStorageVolPtr vol,
>  * @flags: future flags, use 0 for now
>  *
>  * Similar to virStorageVolWipe, but one can choose
>- * between different wiping algorithms.
>+ * between different wiping algorithms. When choosing the
>+ * zero algorithm (VIR_STORAGE_VOL_WIPE_ALG_ZERO), it is
>+ * possible the target storage backend will truncate the
>+ * file rather than writing a stream of zeroes.
>  *
>  * Returns 0 on success, or -1 on error.
>  */
>diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
>index bbf21f6..2531a88 100644
>--- a/src/storage/storage_driver.c
>+++ b/src/storage/storage_driver.c
>@@ -2436,7 +2436,14 @@ storageVolWipePattern(virStorageVolPtr obj,
>         goto cleanup;
>     }
>
>-    ret = backend->wipeVol(obj->conn, pool, vol, algorithm, flags);
>+    if (backend->wipeVol(obj->conn, pool, vol, algorithm, flags) < 0)
>+        goto cleanup;
>+
>+    if (backend->refreshVol &&
>+        backend->refreshVol(obj->conn, pool, vol) < 0)
>+        goto cleanup;
>+
>+    ret = 0;
>
>  cleanup:
>     virStoragePoolObjUnlock(pool);
>diff --git a/tools/virsh.pod b/tools/virsh.pod
>index 21ae4a3..7f6dc8d 100644
>--- a/tools/virsh.pod
>+++ b/tools/virsh.pod
>@@ -3509,6 +3509,11 @@ B<Supported algorithms>
> B<Note>: The availability of algorithms may be limited by the version
> of the C<scrub> binary installed on the host.
>
>+B<Note>: Use of the zero algorithm for some storage backends may result
>+in the truncation of the target file instead of writing all zeroes to the
>+file. The Storage Driver will refresh the volume allocation and capacity
>+after successful volume wipe completion.
>+
> =item B<vol-dumpxml> [I<--pool> I<pool-or-uuid>] I<vol-name-or-key-or-path>
>
> Output the volume information as an XML dump to stdout.
>--
>2.5.0
>
>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151216/76e02b9f/attachment-0001.sig>