linux-ext4 - Re: [PATCH] ext4: introduce per-inode DAX flag

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <20170811121132.bj5y77scrvkgy7uo@rh_laptop>
Date:   Fri, 11 Aug 2017 14:11:32 +0200
From:   Lukas Czerner <lczerner@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     linux-ext4@...r.kernel.org
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
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