Hi, Intel is looking into does it make sense to take an existing, popular filesystem and patch it for write atomicity at the sector count level. Meaning we would protect a configured number of sectors using parameters that each layer in the kernel would synchronize on. We could use a parameter(s) for this that comes from the NVMe specification such as awun or awunpf that set across the (affected) layers to a user space program such as innodb/MySQL which would benefit as would other software. The MySQL target is a strong use case, as its InnoDB has a double write buffer that could be removed if write atomicity was protected at 16KiB for the file opens and with fsync(). My question is why hasn't xfs write atomicity advanced further, as it seems in 3.x kernel time a few years ago this was tried but nothing committed. as documented here: http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/O_ATOMIC Is xfs write atomicity still being pursued , and with what design objective. There is a long thread here, https://lwn.net/Articles/789600/ on write atomicity, but with no progress, lots of ideas in there but not any progress, but I am unclear. Is my design idea above simply too simplistic, to try and protect a configured block size (sector count) through the filesystem and block layers, and what really is not making it attainable? Thanks for the feedback Frank Ober
