On 01/27/2016 03:20 AM, Wido den Hollander wrote:
> When wiping the RBD image will be filled with zeros started
> at offset 0 and until the end of the volume.
>
> This will result in the RBD volume growing to it's full allocation
> on the Ceph cluster. All data on the volume will be overwritten
> however, making it unavailable.
>
> It does NOT take any RBD snapshots into account. The original data
> might still be in a snapshot of that RBD volume.
>
> Signed-off-by: Wido den Hollander <wido@xxxxxxxxx>
> ---
> src/storage/storage_backend_rbd.c | 115 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
> +
> + VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s",
> + info.size, pool->def->source.name, vol->name);
This statement, and others like it, breaks the build on 32-bit
architectures, since info.size is uint64_t but %zu is only 32-bits:
../../src/storage/storage_backend_rbd.c: In function
'virStorageBackendRBDVolWipe':
../../src/storage/storage_backend_rbd.c:1281:15: error: format '%zu'
expects argument of type 'size_t', but argument 8 has type 'uint64_t
{aka long long unsigned int}' [-Werror=format=]
VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s",
^
../../src/util/virlog.h:90:73: note: in definition of macro 'VIR_DEBUG_INT'
virLogMessage(src, VIR_LOG_DEBUG, filename, linenr, funcname, NULL,
__VA_ARGS__)
^
../../src/storage/storage_backend_rbd.c:1281:5: note: in expansion of
macro 'VIR_DEBUG'
VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s",
^
I'm preparing an obvious patch, but was a bit surprised that we don't
have a 32-bit build-bot to have caught it sooner.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list