On Wed, Mar 10, 2021 at 7:53 PM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > On Wed, Mar 10, 2021 at 6:27 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote: > > > On 13:02 10/03, Matthew Wilcox wrote: > > > > On Wed, Mar 10, 2021 at 07:30:41AM -0500, Neal Gompa wrote: > > > > > Forgive my ignorance, but is there a reason why this isn't wired up to > > > > > Btrfs at the same time? It seems weird to me that adding a feature > > > > > > > > btrfs doesn't support DAX. only ext2, ext4, XFS and FUSE have DAX support. > > > > > > > > If you think about it, btrfs and DAX are diametrically opposite things. > > > > DAX is about giving raw access to the hardware. btrfs is about offering > > > > extra value (RAID, checksums, ...), none of which can be done if the > > > > filesystem isn't in the read/write path. > > > > > > > > That's why there's no DAX support in btrfs. If you want DAX, you have > > > > to give up all the features you like in btrfs. So you may as well use > > > > a different filesystem. > > > > > > DAX on btrfs has been attempted[1]. Of course, we could not > > > > But why? A completeness fetish? I don't understand why you decided > > to do this work. > > Isn't DAX useful for pagecache minimization on read even if it is > awkward for a copy-on-write fs? > > Seems it would be a useful case to have COW'd VM images on BTRFS that > don't need superfluous page cache allocations. I could also see this being useful for databases (and maybe even swap files!) on Btrfs, if I'm understanding this feature correctly. -- 真実はいつも一つ！/ Always, there's only one truth!
