Re: [PATCH v2] fuse: keep inode->i_blkbits constant

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Aug 13, 2025 at 10:24:36AM +0200, Miklos Szeredi wrote:
> On Tue, 12 Aug 2025 at 22:44, Joanne Koong <joannelkoong@gmail.com> 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
>