On Wed, Mar 27, 2024 at 03:56:50PM +0000, Trond Myklebust wrote: > On Wed, 2024-03-27 at 15:04 +0000, David Howells wrote: > > Implement a replacement for launder_folio[1]. The key feature of > > invalidate_inode_pages2() is that it locks each folio individually, > > unmaps > > it to prevent mmap'd accesses interfering and calls the - > > >launder_folio() > > address_space op to flush it. This has problems: firstly, each folio > > is > > written individually as one or more small writes; secondly, adjacent > > folios > > cannot be added so easily into the laundry; thirdly, it's yet another > > op to > > implement. > > This is hardly a drop-in replacement for launder_page. The whole point > of using invalidate_inode_pages2() was that it only requires taking the > page locks, allowing us to use it in contexts such as > nfs_release_file(). > > The above use of truncate_inode_pages_range() will require any caller > to grab several locks in order to prevent data loss through races with > write system calls. I don't understand why you need launder_folio now that you have a page_mkwrite implementation (your commit e3db7691e9f3dff3289f64e3d98583e28afe03db used this as justification). Other filesystems (except the network filesystems that copied the NFS implementation) don't implement launder_folio.
