On Mon, 19 Sep 2016 07:11:21 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, Sep 19, 2016 at 01:08:30PM +1000, Nicholas Piggin wrote: > > > Without looking through all the patches again, I believe the issue was > > just that filesystems were not expecting (or at least, not audited to > > expect) pages being added to their pagecache in that particular state > > (they'd expect to go through ->readpage or see !uptodate in prepare_write). > > > > If some wanted to attach metadata to uptodate pages for example, this > > may have caused a problem. It wasn't some big fundamental problem, just a > > mechanical one. > > Umm... Why not make it non-uptodate/locked, try to replace the original > with it in pagecache and then do full-page ->write_begin immediately > followed by full-page ->write_end? Looks like that ought to work in > all in-tree cases... That sounds like it probably should work for that case. IIRC, I was looking at using a write_begin flag to notify the case of of replacing the page, so the fs could also handle the case of replacing existing pagecache. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
