On Thu, May 24, 2018 at 02:13:56PM -0400, Brian Foster wrote: > Ok, so I guess writeback can see uptodate blocks over a hole if some > other block in that page is dirty. Yes. > Perhaps we could make sure that a > dirty page has at least one block that maps to an actual extent or > otherwise the page has been truncated..? We have the following comment near the end of xfs_writepage_map: /* * We can end up here with no error and nothing to write if we * race with a partial page truncate on a sub-page block sized * filesystem. In that case we need to mark the page clean. */ And I'm pretty sure I managed to hit that case easily in xfstests, as my initial handling of it was wrong. So I don't think we can even check for that. > I guess having another dirty block bitmap similar to > iomap_page->uptodate could be required to tell for sure whether a > particular block should definitely have a block on-disk or not. It may > not be worth doing that just for additional error checks, but I still > have to look into the last few patches to grok all the iomap_page stuff. I don't think it's worth it. The sub-page dirty tracking has been one of the issues with the buffer head code that caused a lot of problems, and that we want to get rid of. -- 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
