On 2025/5/6 23:55, Darrick J. Wong wrote: > On Tue, May 06, 2025 at 02:10:12PM +0200, Christoph Hellwig wrote: >> On Tue, May 06, 2025 at 07:25:06PM +0800, Zhang Yi wrote: >>> + if (request_mask & STATX_WRITE_ZEROES_UNMAP && >>> + bdev_write_zeroes_unmap(bdev)) >>> + stat->result_mask |= STATX_WRITE_ZEROES_UNMAP; >> >> That would be my expectation. But then again this area seems to >> confuse me a lot, so maybe we'll get Christian or Dave to chim in. > > Um... does STATX_WRITE_ZEROES_UNMAP protect a field somewhere? > It might be nice to expose the request alignment granularity/max > size/etc. I think that simply returning the support state is sufficient at the moment. __blkdev_issue_write_zeroes() will send write zeroes through multiple iterations, and there are no specific restrictions on the parameters provided by users. > Or does this flag exist solely to support discovering that > FALLOC_FL_WRITE_ZEROES is supported? In which case, why not discover > its existence by calling fallocate(fd, WRITE_ZEROES, 0, 0) like the > other modes? > Current STATX_WRITE_ZEROES_UNMAP and FALLOC_FL_WRITE_ZEROES are inconsistent, we allow users to call fallocate(FALLOC_FL_WRITE_ZEROES) on files that STATX_WRITE_ZEROES_UNMAP is not set. Users can check whether the device supports unmap write zeroes through STATX_WRITE_ZEROES_UNMAP and then decide to call fallocate(FALLOC_FL_WRITE_ZEROES) if it is supported. Please see this explanation for details. https://lore.kernel.org/linux-fsdevel/20250421021509.2366003-1-yi.zhang@xxxxxxxxxxxxxxx/T/#mc1618822bc27d486296216fc1643d5531fee03e1 However, removing STATX_WRITE_ZEROES_UNMAP also seems good to me(Perhaps it would be better.).It means we do not allow to call fallocate(FALLOC_FL_WRITE_ZEROES) if the device does not explicitly support unmap write zeroes. Thanks, Yi.
