lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 11 Aug 2017 14:11:32 +0200
From:   Lukas Czerner <>
To:     Christoph Hellwig <>
Subject: Re: [PATCH] ext4: introduce per-inode DAX flag

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

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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ