On Tue, Feb 23, 2016 at 3:07 PM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: > On 02/24/2016 12:33 AM, Dan Williams wrote: >> The crux of the problem, in my opinion, is that we're asking for an "I >> know what I'm doing" flag, and I expect that's an impossible statement >> for a filesystem to trust generically. If you can get MAP_PMEM_AWARE >> in, great, but I'm more and more of the opinion that the "I know what >> I'm doing" interface should be something separate from today's trusted >> filesystems. >> > > I disagree. I'm not saying any "trust me I know what I'm doing" flag. > the FS reveals nothing and trusts nothing. > All I'm saying is that the libc library I'm using as the new pmem_memecpy() > and I'm using that instead of the old memecpy(). So the FS does not need to > wipe my face after I eat. Failing to do so just means a bug in the application "just means a bug in the application" Who gets the bug report when an app gets its cache syncing wrong and data corruption ensues, and why isn't the fix for that bug that the filesystem simply stops trusting MAP_PMEM_AWARE and synching cachelines on behalf of the app when it calls sync as it must for metadata consistency. Problem solved globally for all broken usages of MAP_PMEM_AWARE and the flag loses all meaning as a result. This is the takeaway I've internalized from Dave's pushback of these new mmap flags. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>