On Wed, Aug 13, 2025 at 10:24:36AM +0200, Miklos Szeredi wrote:
> On Tue, 12 Aug 2025 at 22:44, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
>
> > My understanding is that it's because in that path it uses cached stat
> > values instead of fetching with another statx call to the server so it
> > has to reflect the blocksize the server previously set. It took me a
> > while to realize that the blocksize the server reports to the client
> > is unrelated to whatever blocksize the kernel internally uses for the
> > inode since the kernel doesn't do any block i/o for fuse; the commit
> > message in commit 0e9663ee452ff ("fuse: add blksize field to
> > fuse_attr") says the blocksize attribute is if "the filesystem might
> > want to give a hint to the app about the optimal I/O size".
>
> Right, that's what POSIX says:
>
> st_blksize A file system-specific preferred I/O block size for
> this object. In some file system types, this may
> vary from file to file.
Ahahaha yes, I forgot about that. Regular filesystems can set i_blkbits
to whatever granularity they want and it persists until eviction, and if
they want to trick userspace they set st_blksize to something else.
Kind of like how XFS rounds that up to PAGE_SIZE for 1k fsblock
filesystems.
Now I see what Joanne meant about it taking a while to wrap her head
around i_blkbits vs. st_blksize. Thanks for pointing that out. :)
--D
> Thanks,
> Miklos
>
