On Thu, Aug 24, 2017 at 02:20:57PM -0400, Theodore Ts'o wrote: > The counter-argument is that system administrators do need to have a > way to signal that they would like the file system to "do something > different" on a per-file basis, and no one else has come up with > another way of doing things. Furthermore, it would be highly > desirable if the system adminisator can provide this per-file system > hint with requiring changes to the application. (For example, by > adding madvise/fadvise hints.) We can always add some sort of inode or subtree advice. It's just the binary flag that encodes a specific implementation that is very bad in the long run. > Is that a fair summary of the argument? Otherwise yet. > I have two additional questions I'd like to ask at this point. > > 1) Has there been any other difficulty that XFS has had due to the > fact that they have this DAX flag added? e.g., are there any > operational, or practical code maintainability issues at stake here? > Or is this mostly an design philosophy debate? It hasn't yet. It will create really annoying problems once we use raw DAX access for metadata, which I had prototype a while ago and plan to finnally get in in the next months. > 2) Are there any users using the DAX flag with XFS such that, if XFS > were to remove the DAX flag support, those users would complain > bitterly? I don't know of anyone that actually uses the flag. If someone did that would probably run into problems like changing that changing it on a file that's currently mmaped would crash an burn badly. -- 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
