Re: Meaning of struct statx->stx_blksize field

Re: Meaning of struct statx->stx_blksize field

[Andreas Dilger]

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.   

> 
> Can someone confirm my interpretation, so the man page can be
> corrected? Or do I misunderstand or overlook something?
> 
> Thanks,
> 
> Zeno Endemann


Cheers, Andreas

Re: Meaning of struct statx->stx_blksize field

[Zeno Endemann]

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
> 
> 
> 
> 
> 

Meaning of struct statx->stx_blksize field

[Zeno Endemann]

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.)


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.

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).

Can someone confirm my interpretation, so the man page can be
corrected? Or do I misunderstand or overlook something?

Thanks,

Zeno Endemann