On Tue, Feb 18, 2025 at 09:55:36PM -0800, Christoph Hellwig wrote: > I don't want to block this part as it's an improvement over the current > state, but all these games of trying to detect if discard zeroes all > data despite making no such guarantee whatsoever and being explicitly > allowed to zero some but not all data just feels wrong. > > The right thing would be to use the BLKZEROOUT, but AFAIK the problem is > that dm-thin doesn't support that. Given that the dm-thin discard > implementation seems do always zero, it should be able to just be > reusable for BLKZEROOUT. Can the dm maintainers look into that as it > is a pretty glaring omission? Alternately we could make the log replay program call fallocate(PUNCH_HOLE) on the block device before trying fallocate(ZERO_RANGE) because AFAICT punch-hole has always called blkdev_issue_zeroout with NOFALLBACK. The downside is that fallocate for block devices came long after BLKDISCARD/BLKZEROOUT so we can't remove the BLK* ioctl calls without losing some coverage. --D
