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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
