On Wed, Mar 27, 2019 at 06:00:52AM -0500, Goldwyn Rodrigues wrote: > On 12:10 26/03, Matthew Wilcox wrote: > > On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote: > > > This sets S_DAX in inode->i_flags, which can be used with > > > IS_DAX(). > > > > > > 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. > > > > Congratulations on getting the bear to dance. But why? > > Why not ? ;) 18 files changed, 662 insertions(+), 77 deletions(-) I want to know what advantage we're getting for that. > > To me, the point of btrfs is all the cool stuff it does with built-in > > checksumming and snapshots and RAID and so on. DAX doesn't let you do > > any of that, so why would somebody want to use btrfs to manage DAX? > > There are users who are asking for advantages of dax on btrfs. There are also people asking for perpetual motion machines. Do these users understand the tradeoffs? > I have tried to make it work with snapshots in this series. > Checksumming should be possible, but would require some more hacks. I am > looking into it. > multi-device is an issue for mmap() and I don't think we can work around > it. > > I agree there is a price to pay to use dax, but I am sure the users > would know about that. I really doubt it, to be honest.
