On 02/16/2010 06:33 AM, Daniel P. Berrange wrote:
On Mon, Feb 15, 2010 at 10:47:33PM +0100, Paolo Bonzini wrote:
> On 02/15/2010 10:29 PM, David Allan wrote:
>> * If the volume is a sparse file and the fiemap ioctl is available,
>> use fiemap to locate the volume's extents.
>
> What about for a sparse file doing just
>
> ftruncate (fd, 0);
> ftruncate (fd, st.st_size);
>
> ?
>
> It's already sparse, it doesn't hurt to make it _more_ sparse.
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.
Again, just to be clear, I'm only speaking of regular files here: the
situation you just described seems ok to me, since we're not trying to
protect against attackers on the host. As long as we guarantee that any
read to the file will return zeros following the zero operation, I think
we're ok. Since the section of the POSIX spec that Eric pointed to
makes that guarantee with ftrucate, that's a great option for sparse files.
Can you think of any situation in which we'd want to do a complete
overwrite of a sparse file? At this point, I'm not seeing any. fiemap
is a nice tool, but I think we can dispense with it.
Also, we need to make sure that this code works with physical block
devices, as well as plain files. You can't truncate a block device so
we'll need to write zeros in that case anyway.
That's what it currently does, so we're ok there.
Dave