From: Zeno Endemann <zeno.endemann@mailbox.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Meaning of struct statx->stx_blksize field
Date: Sun, 3 May 2026 15:53:25 +0200 [thread overview]
Message-ID: <b4a08cd3-4ea5-43cf-aa9d-2748f33de3ed@mailbox.org> (raw)
In-Reply-To: <FAE1F98E-276A-4D61-86D4-47AE39F2E7E8@dilger.ca>
Andreas Dilger wrote on 03.05.26 14:41:
> On Apr 27, 2026, at 06:41, Zeno Endemann <zeno.endemann@mailbox.org> wrote:
>>
>> Hi,
>>
>> The man page of statx(2) describes the stx_blksize like so:
>>
>>> The "preferred" block size for efficient filesystem I/O.
>>> (Writing to a file in smaller chunks may cause an
>>> inefficient read-modify-rewrite.)
>
> The statx(2) interface is meant to be able to emulate the stat(2)
> interface, where 'stx_blksize' is reporting the same information
> as 'st_blksize' exactly as documented (preferred IO size),
>
>> However, from observation it rather looks like that field
>> is set to the "block size" (meaning the allocation unit) of
>> the file system the given file resides on - at least for
>> ext4 and vfat.
>
> IIRC, ext2/ext3/ext4 have always returned the blocksize for stat(2)
> st_blksize, so that doesn't prevent the two from being the same.
>
>> To my understanding that value is fairly unrelated to a good
>> IO transfer size and for the most part not really relevant
>> for userspace apps. For avoiding inefficient read-modify
>> rewrite the actual relevant thing is writing in multiples of
>> the page size (unless the page cache is bypassed, in which
>> case I guess stx_dio_offset_align is the value to use).
>
> That is probably more an effect of history rather than anything
> related to statx() itself. ext4 doesn't really have any other
> preference on the IO size other than the blocksize.
Sorry if I'm being a bit pedantic here, but if we are talking
about the filesystem as the underlying data structure, then there
really is no preferred IO size, as long as there is no filesystem-
level block checksumming/encryption (or something to that effect)
in place. Reading or writing single bytes would be just fine from
purely the filesystem perspective regardless of fs blocksize then.
But if we're talking about the filesystem as the filesystem driver,
then I believe it would make sense for it to rather report the page
size than the block size (at least when the block size is smaller),
since the driver is using the page cache to read and write to the
device.
Anyway, I'm not suggesting to change the behavior, just to change
the man page to state that this actually reports the filesystem
block size, which may or may not be a good IO transfer size. So I
wanted to get an approval for that here.
Cheers,
>
>>
>> Can someone confirm my interpretation, so the man page can be
>> corrected? Or do I misunderstand or overlook something?
>>
>> Thanks,
>>
>> Zeno Endemann
>
>
> Cheers, Andreas
>
>
>
>
>
next prev parent reply other threads:[~2026-05-03 13:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 12:41 Meaning of struct statx->stx_blksize field Andreas Dilger
2026-05-03 13:53 ` Zeno Endemann [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-27 10:41 Zeno Endemann
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=b4a08cd3-4ea5-43cf-aa9d-2748f33de3ed@mailbox.org \
--to=zeno.endemann@mailbox.org \
--cc=adilger@dilger.ca \
--cc=linux-fsdevel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox