Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Sat, Mar 13, 2021 at 11:24:00AM -0500, Neal Gompa wrote: > On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski wrote: > > > > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote: > > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote: > > > > 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. > > > > * xfs can shapshot only single files, btrfs entire subvolumes > > * btrfs-send|receive > > * enumeration of changed parts of a file > > XFS cannot do snapshots since it lacks metadata COW. XFS reflinking is > primarily for space efficiency. A reflink is a single-file snapshot. My work team really wants this very patchset -- reflinks on DAX allow backups and/or checkpointing, without stopping the world (there's a single file, "pool", here). Besides, you can still get poor-man's whole-subvolume(/directory) snapshots by manually walking the tree and reflinking everything. That's not atomic -- but rsync isn't atomic either. That's enough for eg. dnf/dpkg purposes. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa! ⠈⠳⣄
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski wrote: > > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote: > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote: > > > 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. > > * xfs can shapshot only single files, btrfs entire subvolumes > * btrfs-send|receive > * enumeration of changed parts of a file > XFS cannot do snapshots since it lacks metadata COW. XFS reflinking is primarily for space efficiency. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote: > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote: > > 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. * xfs can shapshot only single files, btrfs entire subvolumes * btrfs-send|receive * enumeration of changed parts of a file Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢠⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Wed, Mar 10, 2021 at 7:53 PM Dan Williams wrote: > > On Wed, Mar 10, 2021 at 6:27 AM Matthew Wilcox 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!
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Wed, Mar 10, 2021 at 6:27 AM Matthew Wilcox 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.
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On 14:26 10/03, Matthew Wilcox 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. If only I had a penny every time I heard "why would you want to do that?" > > > have checksums or multi-device with it. However, got stuck on > > associating a shared extent on the same page mapping: basically the > > TODO above dax_associate_entry(). > > > > Shiyang has proposed a way to disassociate existing mapping, but I > > don't think that is the best solution. DAX for CoW will not work until > > we have a way of mapping a page to multiple inodes (page->mapping), > > which will convert a 1-N inode-page mapping to M-N inode-page mapping. > > If you're still thinking in terms of pages, you're doing DAX wrong. > DAX should work without a struct page. Not pages specifically, but mappings. fsdax needs the mappings during the page fault and it breaks in case both files fault on the same shared extent. For Reference: WARN_ON_ONCE(page->mapping && page->mapping != mapping) in dax_disassociate_entry(). -- Goldwyn
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
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. > have checksums or multi-device with it. However, got stuck on > associating a shared extent on the same page mapping: basically the > TODO above dax_associate_entry(). > > Shiyang has proposed a way to disassociate existing mapping, but I > don't think that is the best solution. DAX for CoW will not work until > we have a way of mapping a page to multiple inodes (page->mapping), > which will convert a 1-N inode-page mapping to M-N inode-page mapping. If you're still thinking in terms of pages, you're doing DAX wrong. DAX should work without a struct page.
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
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 have checksums or multi-device with it. However, got stuck on associating a shared extent on the same page mapping: basically the TODO above dax_associate_entry(). Shiyang has proposed a way to disassociate existing mapping, but I don't think that is the best solution. DAX for CoW will not work until we have a way of mapping a page to multiple inodes (page->mapping), which will convert a 1-N inode-page mapping to M-N inode-page mapping. [1] https://lore.kernel.org/linux-btrfs/20190429172649.8288-1-rgold...@suse.de/ -- Goldwyn
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Wed, Mar 10, 2021 at 08:36:06AM -0500, Neal Gompa wrote: > On Wed, Mar 10, 2021 at 8:02 AM 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. > > So does that mean that DAX is incompatible with those filesystems when > layered on DM (e.g. through LVM)? Yes. It might be possible to work through RAID-0 or read-only through RAID-1, but I'm not sure anybody's bothered to do that work. > Also, based on what you're saying, that means that DAX'd resources > would not be able to use reflinks on XFS, right? That'd put it in > similar territory as swap files on Btrfs, I would think. You can use DAX with reflinks because the CPU can do read-only mmaps. On a write fault, we break the reflink, copy the data and put in a writable PTE.
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Wed, Mar 10, 2021 at 8:02 AM 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. So does that mean that DAX is incompatible with those filesystems when layered on DM (e.g. through LVM)? Also, based on what you're saying, that means that DAX'd resources would not be able to use reflinks on XFS, right? That'd put it in similar territory as swap files on Btrfs, I would think. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
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.
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Thu, Feb 25, 2021 at 7:23 PM Shiyang Ruan wrote: > > This patchset is attempt to add CoW support for fsdax, and take XFS, > which has both reflink and fsdax feature, as an example. > > Changes from V1: > - Factor some helper functions to simplify dax fault code > - Introduce iomap_apply2() for dax_dedupe_file_range_compare() > - Fix mistakes and other problems > - Rebased on v5.11 > > One of the key mechanism need to be implemented in fsdax is CoW. Copy > the data from srcmap before we actually write data to the destance > iomap. And we just copy range in which data won't be changed. > > Another mechanism is range comparison. In page cache case, readpage() > is used to load data on disk to page cache in order to be able to > compare data. In fsdax case, readpage() does not work. So, we need > another compare data with direct access support. > > With the two mechanism implemented in fsdax, we are able to make reflink > and fsdax work together in XFS. > > > Some of the patches are picked up from Goldwyn's patchset. I made some > changes to adapt to this patchset. > > (Rebased on v5.11) 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 like DAX to work with CoW filesystems is not being wired into *the* CoW filesystem in the Linux kernel that fully takes advantage of copy-on-write. I'm aware that XFS supports reflinks and does some datacow stuff, but I don't know if I would consider XFS integration sufficient for integrating this feature now, especially if it's possible that the design might not work with Btrfs (I hadn't seen any feedback from Btrfs developers, though given how much email there is here, it's entirely possible that I missed it). -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
> > Hi Shiang, > > Thanks for picking up this work. > > On 8:20 26/02, Shiyang Ruan wrote: > > This patchset is attempt to add CoW support for fsdax, and take XFS, > > which has both reflink and fsdax feature, as an example. > > How does this work for read sequence for two different files > mapped to the same extent, both residing in DAX? > > If two different files read the same shared extent, which file > would resultant page->mapping->host point to? > > This problem is listed as a TODO over dax_associate_entry() and is > still not fixed. I have posted another patchset which I called "fix dax-rmap"[1]. It is a try to solve this problem, but still in disscussion for now. [1] https://lkml.org/lkml/2021/2/8/347 -- Thanks, Ruan Shiyang. > > > > -- > Goldwyn
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
Hi Shiang, Thanks for picking up this work. On 8:20 26/02, Shiyang Ruan wrote: > This patchset is attempt to add CoW support for fsdax, and take XFS, > which has both reflink and fsdax feature, as an example. How does this work for read sequence for two different files mapped to the same extent, both residing in DAX? If two different files read the same shared extent, which file would resultant page->mapping->host point to? This problem is listed as a TODO over dax_associate_entry() and is still not fixed. -- Goldwyn
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
hi, First thanks for your patchset. I'd like to know whether your patchset pass fstests? Thanks. Regards, Xiaoguang Wang This patchset is attempt to add CoW support for fsdax, and take XFS, which has both reflink and fsdax feature, as an example. Changes from V1: - Factor some helper functions to simplify dax fault code - Introduce iomap_apply2() for dax_dedupe_file_range_compare() - Fix mistakes and other problems - Rebased on v5.11 One of the key mechanism need to be implemented in fsdax is CoW. Copy the data from srcmap before we actually write data to the destance iomap. And we just copy range in which data won't be changed. Another mechanism is range comparison. In page cache case, readpage() is used to load data on disk to page cache in order to be able to compare data. In fsdax case, readpage() does not work. So, we need another compare data with direct access support. With the two mechanism implemented in fsdax, we are able to make reflink and fsdax work together in XFS. Some of the patches are picked up from Goldwyn's patchset. I made some changes to adapt to this patchset. (Rebased on v5.11) == Shiyang Ruan (10): fsdax: Factor helpers to simplify dax fault code fsdax: Factor helper: dax_fault_actor() fsdax: Output address in dax_iomap_pfn() and rename it fsdax: Introduce dax_iomap_cow_copy() fsdax: Replace mmap entry in case of CoW fsdax: Add dax_iomap_cow_copy() for dax_iomap_zero iomap: Introduce iomap_apply2() for operations on two files fsdax: Dedup file range to use a compare function fs/xfs: Handle CoW for fsdax write() path fs/xfs: Add dedupe support for fsdax fs/dax.c | 532 +++-- fs/iomap/apply.c | 51 fs/iomap/buffered-io.c | 2 +- fs/remap_range.c | 45 +++- fs/xfs/xfs_bmap_util.c | 3 +- fs/xfs/xfs_file.c | 29 ++- fs/xfs/xfs_inode.c | 8 +- fs/xfs/xfs_inode.h | 1 + fs/xfs/xfs_iomap.c | 30 ++- fs/xfs/xfs_iomap.h | 1 + fs/xfs/xfs_iops.c | 11 +- fs/xfs/xfs_reflink.c | 16 +- include/linux/dax.h| 7 +- include/linux/fs.h | 15 +- include/linux/iomap.h | 7 +- 15 files changed, 550 insertions(+), 208 deletions(-)
[PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
This patchset is attempt to add CoW support for fsdax, and take XFS, which has both reflink and fsdax feature, as an example. Changes from V1: - Factor some helper functions to simplify dax fault code - Introduce iomap_apply2() for dax_dedupe_file_range_compare() - Fix mistakes and other problems - Rebased on v5.11 One of the key mechanism need to be implemented in fsdax is CoW. Copy the data from srcmap before we actually write data to the destance iomap. And we just copy range in which data won't be changed. Another mechanism is range comparison. In page cache case, readpage() is used to load data on disk to page cache in order to be able to compare data. In fsdax case, readpage() does not work. So, we need another compare data with direct access support. With the two mechanism implemented in fsdax, we are able to make reflink and fsdax work together in XFS. Some of the patches are picked up from Goldwyn's patchset. I made some changes to adapt to this patchset. (Rebased on v5.11) == Shiyang Ruan (10): fsdax: Factor helpers to simplify dax fault code fsdax: Factor helper: dax_fault_actor() fsdax: Output address in dax_iomap_pfn() and rename it fsdax: Introduce dax_iomap_cow_copy() fsdax: Replace mmap entry in case of CoW fsdax: Add dax_iomap_cow_copy() for dax_iomap_zero iomap: Introduce iomap_apply2() for operations on two files fsdax: Dedup file range to use a compare function fs/xfs: Handle CoW for fsdax write() path fs/xfs: Add dedupe support for fsdax fs/dax.c | 532 +++-- fs/iomap/apply.c | 51 fs/iomap/buffered-io.c | 2 +- fs/remap_range.c | 45 +++- fs/xfs/xfs_bmap_util.c | 3 +- fs/xfs/xfs_file.c | 29 ++- fs/xfs/xfs_inode.c | 8 +- fs/xfs/xfs_inode.h | 1 + fs/xfs/xfs_iomap.c | 30 ++- fs/xfs/xfs_iomap.h | 1 + fs/xfs/xfs_iops.c | 11 +- fs/xfs/xfs_reflink.c | 16 +- include/linux/dax.h| 7 +- include/linux/fs.h | 15 +- include/linux/iomap.h | 7 +- 15 files changed, 550 insertions(+), 208 deletions(-) -- 2.30.1
