On 2017-09-12 20:52, Timofey Titovets wrote:
No, no, no, no...
No new ioctl, no change in fallocate.
Fisrt: VM can do punch hole, if you use qemu -> qemu know how to do it.
Windows Guest also know how to do it.
Different Hypervisor? -> google -> Make issue to support, all
Linux/Windows/Mac OS support holes in files.
Not everybody who uses sparse files is using virtual machines.
No new code, no new strange stuff to fix not broken things.
Um, the fallocate PUNCH_HOLE mode _is_ broken. There's a race condition
that can trivially cause data loss.
You want replace zeroes? EXTENT_SAME can do that.
But only on a small number of filesystems, and it requires extra work
that shouldn't be necessary.
truncate -s 4M test_hole
dd if=/dev/zero of=./test_zero bs=4M
duperemove -vhrd ./test_hole ./test_zero
And performance for this approach is absolute shit compared to fallocate -d.
Actual numbers, using a 4G test file (which is still small for what
you're talking about) and a 4M hole file:
fallocate -d: 0.19 user, 0.85 system, 1.26 real
duperemove -vhrd: 0.75 user, 137.70 system, 144.80 real
So, for a 4G file, it took duperemove (and the EXTENT_SAME ioctl) 114.92
times as long to achieve the same net effect. From a practical
perspective, this isn't viable for regular usage just because of how
long it takes. Most of that overhead is that the EXTENT_SAME ioctl does
a byte-by-byte comparison of the ranges to make sure they match, but
that isn't strictly necessary to avoid this race condition. All that's
actually needed is determining if there is outstanding I/O on that
region, and if so, some special handling prior to freezing the region is
needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
