[libvirt] [PATCH v2] storage: Attempt to refresh volume after successful wipe volume
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.
Signed-off-by: John Ferlan <jferlan(a)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