[LTP] [PATCH v2] syscalls/stat04&lstat03: remove fs block size related code

[Andrea Cervesato]

Hi!

Sorry for the delay to this review.

On Thu Nov 13, 2025 at 5:22 PM CET, Zorro Lang via ltp wrote:
> The st_blksize isn't equivalent to the filesystem block size. The
> stat(3) manual describe st_blksize as:
>
>   "This field gives the "preferred" block size for efficient filesystem I/O."
>
> So the st_blksize is the "preferred" block size for "efficient" fs
> I/O, extN might think the "preferred" block size is fs block size.
> But not all filesystems think same with extN. For example, xfs thinks
> the "preferred" block size is:
>
>   max_t(uint32_t, PAGE_SIZE, mp->m_sb.sb_blocksize)
>
> So you might get st_blksize=4096, no matter on 1k blocksize xfs or 4k
> blocksize xfs. We shouldn't expect to use a different blocksize mkfs
> option to get a different st_blksize. This part of code is useless,
> except causing unexpected test failures on other filesystems (e.g.
> xfs, btrfs and so on).
>
> Signed-off-by: Zorro Lang <zlang@kernel.org>
> ---
>
> Hi,
>
> I tried to fix the mkfs problem last year:
>   https://lists.linux.it/pipermail/ltp/2024-December/041038.html
>
> Now I got a chance to look back this test failure, I think it's not a mkfs
> option problem, but the test case misunderstood the st_blksize.
>
> Except we limit this test only run on extN, or we don't need to make
> fs with a different block size, especially shouldn't expect to get
> a different st_blksize from that.

If testing `st_blksize` is an issue only under certain filesystems, we
should probably test it only when the right ones are in use.
For instance, this can be done as following :

	if (!strcmp(tst_device->fs_type, "ext2")) {
		/* test `st_blocks` attribute */
	}

In this way we avoid to disable `st_blksize` testing for all existing
filesystems.

-- 
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com