Re: fallocate(FALLOC_FL_ZERO_RANGE_BUT_REALLY) to avoid unwritten extents?
From: Avi Kivity <hidden>
Date: 2021-01-04 19:58:34
Also in:
linux-block, linux-fsdevel, linux-xfs
On 04/01/2021 21.10, Andres Freund wrote:
Hi, On 2021-01-04 10:19:58 -0800, Darrick J. Wong wrote:quoted
On Tue, Dec 29, 2020 at 10:28:19PM -0800, Andres Freund wrote:quoted
Would it make sense to add a variant of FALLOC_FL_ZERO_RANGE that doesn't convert extents into unwritten extents, but instead uses blkdev_issue_zeroout() if supported? Mostly interested in xfs/ext4 myself, but ... Doing so as a variant of FALLOC_FL_ZERO_RANGE seems to make the most sense, as that'd work reasonably efficiently to initialize newly allocated space as well as for zeroing out previously used file space. As blkdev_issue_zeroout() already has a fallback path it seems this should be doable without too much concern for which devices have write zeroes, and which do not?Question: do you want the kernel to write zeroes even for devices that don't support accelerated zeroing?I don't have a strong opinion on it. A complex userland application can do a bit better job managing queue depth etc, but otherwise I suspect doing the IO from kernel will win by a small bit. And the queue-depth issue presumably would be relevant for write-zeroes as well, making me lean towards just using the fallback.
The new flag will avoid requiring DMA to transfer the entire file size, and perhaps can be implemented in the device by just adjusting metadata. So there is potential for the new flag to be much more efficient. But note it will need to be plumbed down to md and dm to be generally useful.