On Tue, Jan 17, 2017 at 7:59 AM, Jan Kara <jack@xxxxxxx> wrote: > On Fri 13-01-17 17:20:08, Ross Zwisler wrote: >> - The DAX fsync/msync model was built for platforms that need to flush dirty >> processor cache lines in order to make data durable on NVDIMMs. There exist >> platforms, however, that are set up so that the processor caches are >> effectively part of the ADR safe zone. This means that dirty data can be >> assumed to be durable even in the processor cache, obviating the need to >> manually flush the cache during fsync/msync. These platforms still need to >> call fsync/msync to ensure that filesystem metadata updates are properly >> written to media. Our first idea on how to properly support these platforms >> would be for DAX to be made aware that in some cases doesn't need to keep >> metadata about dirty cache lines. A similar issue exists for volatile uses >> of DAX such as with BRD or with PMEM and the memmap command line parameter, >> and we'd like a solution that covers them all. > > Well, we still need the radix tree entries for locking. And you still need > to keep track of which file offsets are writeably mapped (which we > currently implicitely keep via dirty radix tree entries) so that you can > writeprotect them if needed (during filesystem freezing, for reflink, ...). > So I think what is going to gain the most by far is simply to avoid doing > the writeback at all in such situations. I came to the same conclusion when taking a look at this. I have some patches that simply make the writeback optional, but do not touch any of the other dirty tracking infrastructure. I'll send them out shortly after a bit more testing. This also dovetails with the request from Linus to push pmem flushing routines into the driver and stop abusing __copy_user_nocache. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
