On Thu, Feb 13, 2020 at 08:42:42PM -0800, Darrick J. Wong wrote: > On Thu, Feb 13, 2020 at 03:33:08PM -0700, Allison Collins wrote: > > I also understand there are multiple ways to solve this problem that people > > may have opinions on. I've noticed some older patch sets trying to use a > > flag to control when dirty pages are flushed, though I think our customer > > would like to see a hardware solution via NVMe devices. So I would like to > > see if others have similar interests as well and what their thoughts may be. > > Thanks everyone! > > Hmmm well there are a number of different ways one could do this-- Interesting. Your answer implies a question of "How do we expose a filesystem's ability to do atomic writes to userspace", whereas I thought Allison's question was "What spec do we write to give to the NVMe vendors so that filesystems can optimise their atomic writes". I am very interested in the question of atomic writes, but I don't know that we're going to have the right people in the room to design a userspace API. Maybe this is more of a Plumbers topic? I think the two main users of a userspace API would be databases (sqlite, mysql, postgres, others) and package managers (dpkg, rpm, others?). Then there would be the miscellaneous users who just want things to work and don't really care about performance (writing a game's high score file, updating /etc/sudoers). That might argue in favour of having two independent APIs, one that's simple, probably quite slow, but safe, and one that's complex, fast and safe. There's also an option for simple, fast and unsafe, but, y'know, we already have that ... Your response also implies that atomic writes are only done to a single file at a time, which isn't true for either databases or for package managers. I wonder if the snapshot/reflink paradigm is the right one for multi-file atomic updates, or if we can use the same underlying mechanism to implement an API which better fits how userspace actually wants to do atomic updates.
