On Tue, 14 Jan 2025 at 09:38, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > Maybe an explicit callback from the migration code to the filesystem > would work. I.e. move the complexity of dealing with migration for > problematic filesystems (netfs/fuse) to the filesystem itself. I'm > not sure how this would actually look, as I'm unfamiliar with the > details of page migration, but I guess it shouldn't be too difficult > to implement for fuse at least. Thinking a bit... 1) reading pages Pages are allocated (PG_locked set, PG_uptodate cleared) and passed to ->readpages(), which may make the pages uptodate asynchronously. If a page is unlocked but not set uptodate, then caller is supposed to retry the reading, at least that's how I interpret filemap_get_pages(). This means that it's fine to migrate the page before it's actually filled with data, since the caller will retry. It also means that it would be sufficient to allocate the page itself just before filling it in, if there was a mechanism to keep track of these "not yet filled" pages. But that probably off topic. 2) writing pages When the page isn't actually being copied, the writeback could be cancelled and the page redirtied. At which point it's fine to migrate it. The problem is with pages that are spliced from /dev/fuse and control over when it's being accessed is lost. Note: this is not actually done right now on cached pages, since writeback always copies to temp pages. So we can continue to do that when doing a splice and not risk any performance regressions. Am I missing something? Thanks, Miklos
