Thread (2 messages) 2 messages, 2 authors, 2017-01-17

Re: [LSF/MM TOPIC] Future direction of DAX

From: Jeff Moyer <hidden>
Date: 2017-01-17 14:54:27
Also in: linux-fsdevel, linux-mm, nvdimm

Christoph Hellwig [off-list ref] writes:
On Mon, Jan 16, 2017 at 05:50:33PM -0800, Darrick J. Wong wrote:
quoted
I wouldn't consider it a barrier in general (since ext4 also prints
EXPERIMENTAL warnings for DAX), merely one for XFS.  I don't even think
it's that big of a hurdle -- afaict XFS ought to be able to achieve this
by modifying iomap_begin to allocate new pmem blocks, memcpy the
contents, and update the memory mappings.  I think.
Ah, I wasn't even thinking about non PMEM_IMMUTABLE usage.
Yes, and I have a working prototype for that.  I'm just way to busy
with lots of bugfixing at the moment but I plan to get to it in this
merge window.  I also agree that we can't mark a feature as fully
supported until it doesn't conflict with other features.
Fair enough.
And I'm not going to get start on the PMEM_IMMUTABLE bullshit, please
don't even go there folks, it's a dead end.
I spoke with Dave before the holidays, and he indicated that
PMEM_IMMUTABLE would be an acceptable solution to allowing applications
to flush data completely from userspace.  I know this subject has been
beaten to death, but would you mind just summarizing your opinion on
this one more time?  I'm guessing this will be something more easily
hashed out at LSF, though.

Thanks,
Jeff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help