Re: [PATCH v1] src/stat_test.c: add STATX_DIOALIGN support

[Eric Biggers <ebiggers@kernel.org>]

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