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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Feb 2019 10:17:30 -0800 From: Dan Williams <dan.j.williams@...el.com> To: Ric Wheeler <ricwheeler@...il.com> Cc: lsf-pc@...ts.linux-foundation.org, linux-nvdimm <linux-nvdimm@...ts.01.org>, linux-xfs <linux-xfs@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-ext4 <linux-ext4@...r.kernel.org> Subject: Re: [LSF/MM TOPIC] The end of the DAX experiment On Sun, Feb 17, 2019 at 12:29 PM Ric Wheeler <ricwheeler@...il.com> wrote: > > On 2/6/19 4:12 PM, Dan Williams wrote: > > Before people get too excited this isn't a proposal to kill DAX. The > > topic proposal is a discussion to resolve lingering open questions > > that currently motivate ext4 and xfs to scream "EXPERIMENTAL" when the > > current DAX facilities are enabled. The are 2 primary concerns to > > resolve. Enumerate the remaining features/fixes, and identify a path > > to implement it all without regressing any existing application use > > cases. > > > > An enumeration of remaining projects follows, please expand this list > > if I missed something: > > > > * "DAX" has no specific meaning by itself, users have 2 use cases for > > "DAX" capabilities: userspace cache management via MAP_SYNC, and page > > cache avoidance where the latter aspect of DAX has no current api to > > discover / use it. The project is to supplement MAP_SYNC with a > > MAP_DIRECT facility and MADV_SYNC / MADV_DIRECT to indicate the same > > dynamically via madvise. Similar to O_DIRECT, MAP_DIRECT would be an > > application hint to avoid / minimiize page cache usage, but no strict > > guarantee like what MAP_SYNC provides. > > > Sounds like a great topic to me. Having just gone through a new round of USENIX > paper reviews, it is interesting to see how many academic systems are being > pitched in this space (and most of them don't mention the kernel based xfs/ext4 > with dax). Makes sense, the current fsdax facility is chasing feature deficiencies relative to device-dax (longterm pin support) and nova (dax techniques for fs-metadata).
Powered by blists - more mailing lists