From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Zorro Lang" <zlang@kernel.org>, <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v2] syscalls/stat04&lstat03: remove fs block size related code
Date: Thu, 18 Dec 2025 14:36:46 +0100 [thread overview]
Message-ID: <DF1DSNN2O3LK.2NIRU59O5LLY6@suse.com> (raw)
In-Reply-To: <20251113162217.1077332-1-zlang@kernel.org>
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
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2025-12-18 13:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 16:22 [LTP] [PATCH v2] syscalls/stat04&lstat03: remove fs block size related code Zorro Lang via ltp
2025-12-18 13:36 ` Andrea Cervesato via ltp [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DF1DSNN2O3LK.2NIRU59O5LLY6@suse.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.