The issue that I've found people don't fully grok w.r.t. volatile pages is that it doesn't just change the cache state of the page. When a volatile page is removed from memory, it *punches a hole* in the file - it physically discards the data from the file. IOWs, it's not just removed from memory, it's also removed from the underlying storage.
This key behaviour isn't mentioned at all in the article - it only talks about page cache and memory management. In reality, the volatile pages API is an asynchronous, memory-demand driven hole punch operation. This is a real filesystem operation, and the focus on tmpfs seems to blind people as to what the true data integrity ramifications of the operation are.
Fundamentally, the difference between current fadvise operations and volatile pages is that fadvise() never changes the contents of the file, just how it is cached and read. Every time you read that data it is guaranteed to be the same, even if it was removed from cache. If you mark that same range as volatile pages, there is no guarantee the data is the same next time you read it because the page may have been removed from both the page cache and the underlying storage. IOWs, VOLATILE is not an advisory operation - it is a _data manipulation operation_ that destroys data.
That's why I said fallocate() is more appropriate than fadvise() - fadvise() only affects in-memory page cache behaviour, and has no implications for data integrity. Removing volatile pages from memory is a an asynchronous hole punching operation, and hole punching is something we use fallocate() for. :)