On Tue, Aug 12, 2025 at 12:59 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> On Tue, Aug 12, 2025 at 10:27:41AM +0200, Miklos Szeredi wrote:
> > On Thu, 7 Aug 2025 at 19:51, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > >
> > > With fuse now using iomap for writeback handling, inode blkbits changes
> > > are problematic because iomap relies on inode->i_blkbits for its
> > > internal bitmap logic. Currently we change inode->i_blkbits in fuse to
> > > match the attr->blksize value passed in by the server.
> > >
> > > This commit keeps inode->i_blkbits constant in fuse. Any attr->blksize
> > > values passed in by the server will not update inode->i_blkbits. The
> > > client-side behavior for stat is unaffected, stat will still reflect the
> > > blocksize passed in by the server.
> >
> > Not quite. You also need to save ilog2(attr->blksize) in
> > fi->orig_i_blkbits and restore it after calling generic_fillattr() in
> > fuse_update_get_attr() just like it's done for i_mode and i_ino.
>
> Why is that? Is the goal here that fstat() should always return the
> most recent blocksize the fuse server reported, even if the pagecache
> accounting still uses the blocksize first reported when the kernel
> created the incore struct inode?
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".
Thanks,
Joanne
>
> --D
