On 08/19/2018 11:56 AM, Nir Soffer wrote:
When using file systems not supporting ZERO_RANGE (e.g. NFS 4.2) or
block device on kernel < 4.9, we used to call fallocate() for every
zero, fail with EOPNOTSUPP, and fallback to manual zeroing. When
trimming, we used to try unsupported fallocate() on every call.
Change file handle to remember if punching holes or zeroing range are
supported, and avoid unsupported calls.
- zero changed to:
1. If we can punch hole and may trim, try PUNCH_HOLE
2. If we can zero range, try ZERO_RANGE
3. Fall back to manual writing
- trim changed to:
1. If we can punch hole, try PUNCH_HOLE
2. Succeed
---
plugins/file/file.c | 84 +++++++++++++++++++++++++++++----------------
1 file changed, 55 insertions(+), 29 deletions(-)
@@ -146,6 +149,18 @@ file_open (int readonly)
return NULL;
}
+#ifdef FALLOC_FL_PUNCH_HOLE
+ h->can_punch_hole = true;
+#else
+ h->can_punch_hole = false;
+#endif
h was allocated with malloc(). If we switched to allocating with
calloc(), we could get rid of the '= false' branches, for fewer lines.
Not a big enough deal for me to care (so I didn't modify anything).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org