On Fri, Aug 11, 2017 at 03:01:47AM -0700, Christoph Hellwig wrote: > On Tue, Aug 08, 2017 at 11:00:16AM +0200, Lukas Czerner wrote: > > So I've read the thread where you talk about this. I do not see anything > > about it being a masive mistake. I only see that you're confident that's > > it's a wrong thing to do. Like you're ever not confident about > > something;) Care to elaborate on what's wrong with it and why we do not > > want it ? On the surface it does look like a usefull option to have. > > The problem is that DAX is an implementation detail on how to write > data back. It has absolutely no user visible semantics. Encoding > such a detail in the on-disk format is not a good idea. Thanks, for the answer. I do not know too much about the DAX enabled HW. However I do know that there is some variety to it, some can be faster than DRAM, some can be slower, or on-par with DRAM. Some can be more expensive, hence probably smaller, some cheaper and bigger. What about latency and throughput can there be difference as well ? That said, it seems to me that there can be some user choice involved in this at least based on the fact that when DAX is used system memory is not used. So for example when DAX HW is slower than system memory, user can make a choice to exclude some inodes to speed up particular workload, while saving system memory where it does not matter as much. Also can this flag play a role in situation of hierarchical, or heterogeneous storage where dax enabled hardware is used ? Seems to me that it might. What I am trying to say is that while you say that it has no user visible semantics, it does have effect on the system that should not be simply ignored. -Lukas
