On Fri, Jan 31, 2020 at 03:31:58PM -0800, Dan Williams wrote: > > Should we (XFS) make fallocate(ZERO_RANGE) detect when it's operating on > > a written extent in a DAX file and call this instead of what it does now > > (punch range and reallocate unwritten)? > > If it eliminates more block assumptions, then yes. In general I think > there are opportunities to use "native" direct_access instead of > block-i/o for other areas too, like metadata i/o. Yes, and at least for XFS there aren't too many places where we rely on block I/O after this. It is the buffer cache and the log code, and I actually have a WIP conversion for the latter here: http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-log-dax which I need to dust off, similar with the cache flushing changes. But more importantly with just the patch in this thread we should be able to stop the block device pointer in struct iomap for DAX file systems, and thus be able to union the bdev, dax_dev and inline data fields, which should make their usage much more clear, and reduce the stack footprint. > (d) dax fsync is just cache flush, so it can't fail, or are you > talking about errors in metadata? And based on our discussion even that cache flush sounds like a bad idea, and might be a reason why all the file system bypass or weirdo file systems are faster than XFS.
