Re: [Libguestfs] [PATCH] file: Zero support for block devices and NFS 4.2

On 07/29/2018 07:04 AM, Nir Soffer wrote: >If we may not trim, we tried ZERO_RANGE, but this is not well supported >yet, for example it is not available on NFS 4.2. ZERO_RANGE and >PUNCH_HOLE are supported now on block devices, but not on RHRL 7, so we >fallback to slow manual zeroing there. > >Change the logic to support block devices on RHEL 7, and file systems >that do not support ZERO_RANGE. > >The new logic: >- If we may trim, try PUNCH_HOLE >- If we can zero range, Try ZERO_RANGE >- If we can punch hole and fallocate, try fallocate(PUNCH_HOLE) followed > by fallocate(0). >- If underlying file is a block device, try ioctl(BLKZEROOUT) >- Otherwise fallback to manual zeroing > >The handle keeps now the underlying file capabilities, so once we >discover that an operation is not supported, we never try it again. > > >Issues: >- ioctl(BLKZEROOUT) will fail if offset or count are not aligned to > logical sector size. I'm not sure if nbdkit or qemu-img ensure this. qemu-img tends to default to 512-byte alignment, but can be told to follow 4k alignment instead. nbdkit includes a filter that can force 4k alignment on top of any plugin, regardless of client alignment. Someday, I'd like to enhance nbdkit to support block size advertisement (qemu-img already knows how to honor such advertisements). It's on my todo queue, but lower in priority than getting incremental backups working in libvirt.