lkml.org 
[lkml]   [2016]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
    On Mon, Sep 12, 2016 at 05:25:15PM +1000, Oliver O'Halloran wrote:
    > What are the problems here? Is this a matter of existing filesystems
    > being unable/unwilling to support this or is it just fundamentally
    > broken?

    It's a fundamentally broken model. See Dave's post that actually was
    sent slightly earlier then mine for the list of required items, which
    is fairly unrealistic. You could probably try to architect a file
    system for it, but I doubt it would gain much traction.

    > The end goal is to let applications manage the persistence of
    > their own data without having to involve the kernel in every IOP, but
    > if we can't do that then what would a 90% solution look like? I think
    > most people would be OK with having to do an fsync() occasionally, but
    > not after ever write to pmem.

    You need an fsync for each write that you want to persist. This sounds
    painful for now. But I have an implementation that will allow the
    atomic commit of more or less arbitrary amounts of previous writes for
    XFS that I plan to land once the reflink work is in.

    That way you create almost arbitrarily complex data structures in your
    programs and commit them atomicly. It's not going to fit the nvml
    model, but that whole think has been complete bullshit since the
    beginning anyway.

    \
     
     \ /
      Last update: 2016-09-17 09:59    [W:7.848 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site