On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx> > > This sets S_DAX in inode->i_flags, which can be used with > IS_DAX(). I haven't followed the dax developments recently, IIRC the mount option 'dax' was meant to be a temporary solution. I don't know if this has stuck, or is discouraged to be added to new code. The replacement is the per-inode xflag. > The dax option is restricted to non multi-device mounts. > dax interacts with the device directly instead of using bio, so > all bio-hooks which we use for multi-device cannot be performed > here. While regular read/writes could be manipulated with > RAID0/1, mmap() is still an issue. > > Auto-setting free space tree, because dealing with free space > inode (specifically readpages) is a nightmare. > Auto-setting nodatasum because we don't get callback for writing > checksums after mmap()s. As discussed before, mandating free-space-tree for dax is ok and even more that it does not complicate the space cache v1 code. > Store the dax_device in fs_info which will be used in iomap code. > Question: Since we have only one dax device, I thought fs_info is > the best place. However, should it moved to btrfs_device? At this point it's probably ok to store it in fs_info as the multi-device support does not exist. If this changes, then the device is the right place. As Adam mentioned, support for the 'single' profile would be nice. It's the simplest profile that over multiple devices only splits the logical address space (of btrfs) into more chunks. However I don't know if the dax side does require something that makes this impossible to coexist.
