On Fri, Jan 06, 2023 at 07:10:04PM +0800, Boyang Xue wrote: > I planned to test this functionality by hacking generic/423, which I > think is a good framework for doing basic statx() validation, like > > ref_dio_mem_align=$(cat /sys/block/<dev>/queue/logical_block_size) > ref_dio_offset_align=$(($(cat /sys/block/<dev>/queue/dma_alignment)+1)) > ... > check_stat $TEST_DIR/$seq-file \ > stx_dio_mem_align=$ref_dio_mem_align \ > stx_dio_offset_align=$ref_dio_offset_align > > I think this is adequate for a basic correctness test? Not in general. The logical_block_size and dma_alignment+1 of the block device (assuming the filesystem has a block device, and only one of them...) are only the *typical* values for stx_dio_mem_align and stx_dio_offset_align. They are *not* the guaranteed values, since the DIO support and alignment restrictions are filesystem-specific. They depend on the filesystem type, mkfs options, mount options, kernel version, block device, and other things. So if you add the above, it will make generic/423 fail in various cases. This problem is the whole reason that STATX_DIOALIGN was added: it provides a way to query DIO support and alignment restrictions. If there was already another way to *reliably* query DIO support and alignment restrictions, then there would have been no need to add STATX_DIOALIGN. Nonetheless, see my previous email for some ideas about tests of STATX_DIOALIGN that might be possible. Another idea is to test STATX_DIOALIGN on a block device node, not a regular file. The results from block devices are more predictable; currently STATX_DIOALIGN on a block device always reports logical_block_size and dma_alignment+1. Though, that could still change in future kernel versions. - Eric
