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