On 02/16/2010 07:36 AM, Daniel P. Berrange wrote:
On Tue, Feb 16, 2010 at 01:31:58PM +0100, Paolo Bonzini wrote:
On 02/16/2010 12:33 PM, Daniel P. Berrange wrote:
The idea of zeroing upon delete, is that we want the currently allocated
extents to be overwritten with zeros. If we truncate to 0 size, then
extend to original size I imagine that would easily allow the filesystem
to give you a new set of extents filled with zeros, leaving the old
extents with data intact as unused space on the FS.
Yeah, as long as you use regular files as images you're safe, but you'd
expose the old data if you destroyed the partition on which the file
resided and used the partition as storage for a new guest.
But then in this scenario (delete file system partition and give it out
as raw) you could expose information not only about other/old guests,
but also about the host. So for partitions it can be even more
important to provide an option to zero the partition _before_ giving it
out. Currently you cannot do that with libvirt.
There is an unused 'flags' parameter in virStorageVolCreate(), where
we could/should add a VIR_STORAGE_VOL_CREATE_ZEROED parameter too
for that scenario
ANother option would be to add an explicit virStorageVolZero() API to
allow a volume to be wiped independently of create/delete operations.
I like this approach. Since the code is already written for pretty much
every permutation: regular non-sparse file, regular sparse file, block
device, adding the new API isn't a lot of work. That gives users the
greatest flexibility for choosing the time of the zero operation, which
is important since it's time consuming.
Dave
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list