On Mon, Jul 28, 2025 at 10:34 AM Matthew Wilcox willy@infradead.org wrote:
On Fri, Jul 25, 2025 at 06:16:15PM -0700, Joanne Koong wrote:
Also, I just noticed that apparently the blocksize can change dynamically for an inode in fuse through getattr replies from the server (see fuse_change_attributes_common()). This is a problem since the iomap uses inode->i_blkbits for reading/writing to the bitmap. I think we will have to cache the inode blkbits in the iomap_folio_state struct unfortunately :( I'll think about this some more and send out a patch for this.
Does this actually happen in practice, once you've started _using_ the block device? Rather than all this complicated stuff to invalidate the page cache based on the fuse server telling us something, maybe just declare the server to be misbehaving and shut the whole filesystem down?
I don't think this case is likely at all but I guess one scenario where the server might want to change the block size midway through is if they send the data to some network filesystem on the backend and if that backend shuts down or is at full capacity for whatever reason and they need to migrate to another backend that uses a different block size then I guess this would be useful for that.
fuse currently does allow the block size to be changed dynamically so I'm not sure if we can change that behavior without breaking backwards compatibility.