Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
The patch numbering due looks odd due to the combination of the two series. But otherwise this looks good to me modulo the one minor nitpick.
Re: [PATCH v11 06/07] xfs: support CoW in fsdax mode
在 2022/5/10 13:45, Christoph Hellwig 写道:
+#ifdef CONFIG_FS_DAX
+int
+xfs_dax_fault(
+ struct vm_fault *vmf,
+ enum page_entry_sizepe_size,
+ boolwrite_fault,
+ pfn_t *pfn)
+{
+ return dax_iomap_fault(vmf, pe_size, pfn, NULL,
+ (write_fault && !vmf->cow_page) ?
+ &xfs_dax_write_iomap_ops :
+ &xfs_read_iomap_ops);
+}
+#endif
Is there any reason this is in xfs_iomap.c and not xfs_file.c?
Yes, It's better to put it in xfs_file.c since it's the only caller. I
didn't notice it...
--
Thanks,
Ruan.
Otherwise the patch looks good:
Reviewed-by: Christoph Hellwig
[PATCH] dax: use kobj_to_dev()
From: Minghao Chi
Use kobj_to_dev() instead of open-coding it.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
drivers/dax/bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 1dad813ee4a6..f0f45962005d 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -512,7 +512,7 @@ static DEVICE_ATTR_WO(delete);
static umode_t dax_region_visible(struct kobject *kobj, struct attribute *a,
int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct dax_region *dax_region = dev_get_drvdata(dev);
if (is_static(dax_region))
@@ -1241,7 +1241,7 @@ static DEVICE_ATTR_RO(numa_node);
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int
n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct dev_dax *dev_dax = to_dev_dax(dev);
struct dax_region *dax_region = dev_dax->region;
--
2.25.1
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Sun, May 08, 2022 at 10:36:06PM +0800, Shiyang Ruan wrote: > This is a combination of two patchsets: > 1.fsdax-rmap: > https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ > 2.fsdax-reflink: > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ > > Changes since v13 of fsdax-rmap: > 1. Fixed mistakes during rebasing code to latest next- > 2. Rebased to next-20220504 > > Changes since v10 of fsdax-reflink: > 1. Rebased to next-20220504 and fsdax-rmap > 2. Dropped a needless cleanup patch: 'fsdax: Convert dax_iomap_zero to > iter model' > 3. Fixed many conflicts during rebasing > 4. Fixed a dedupe bug in Patch 05: the actuall length to compare could be > shorter than smap->length or dmap->length. > PS: There are many changes during rebasing. I think it's better to > review again. > > == > Shiyang Ruan (14): > fsdax-rmap: > dax: Introduce holder for dax_device > mm: factor helpers for memory_failure_dev_pagemap > pagemap,pmem: Introduce ->memory_failure() > fsdax: Introduce dax_lock_mapping_entry() > mm: Introduce mf_dax_kill_procs() for fsdax case Hmm. This patchset touches at least the dax, pagecache, and xfs subsystems. Assuming it's too late for 5.19, how should we stage this for 5.20? I could just add the entire series to iomap-5.20-merge and base the xfs-5.20-merge off of that? But I'm not sure what else might be landing in the other subsystems, so I'm open to input. --D > xfs: Implement ->notify_failure() for XFS > fsdax: set a CoW flag when associate reflink mappings > fsdax-reflink: > 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 zero > fsdax: Dedup file range to use a compare function > xfs: support CoW in fsdax mode > xfs: Add dax dedupe support > > drivers/dax/super.c | 67 +- > drivers/md/dm.c | 2 +- > drivers/nvdimm/pmem.c | 17 ++ > fs/dax.c| 398 ++-- > fs/erofs/super.c| 13 +- > fs/ext2/super.c | 7 +- > fs/ext4/super.c | 9 +- > fs/remap_range.c| 31 ++- > fs/xfs/Makefile | 5 + > fs/xfs/xfs_buf.c| 10 +- > fs/xfs/xfs_file.c | 9 +- > fs/xfs/xfs_fsops.c | 3 + > fs/xfs/xfs_inode.c | 69 ++- > fs/xfs/xfs_inode.h | 1 + > fs/xfs/xfs_iomap.c | 46 - > fs/xfs/xfs_iomap.h | 3 + > fs/xfs/xfs_mount.h | 1 + > fs/xfs/xfs_notify_failure.c | 220 > fs/xfs/xfs_reflink.c| 12 +- > fs/xfs/xfs_super.h | 1 + > include/linux/dax.h | 56 - > include/linux/fs.h | 12 +- > include/linux/memremap.h| 12 ++ > include/linux/mm.h | 2 + > include/linux/page-flags.h | 6 + > mm/memory-failure.c | 257 --- > 26 files changed, 1087 insertions(+), 182 deletions(-) > create mode 100644 fs/xfs/xfs_notify_failure.c > > -- > 2.35.1 > > >
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
[ add Andrew ] On Tue, May 10, 2022 at 6:49 PM Dave Chinner wrote: > > On Tue, May 10, 2022 at 05:03:52PM -0700, Darrick J. Wong wrote: > > On Sun, May 08, 2022 at 10:36:06PM +0800, Shiyang Ruan wrote: > > > This is a combination of two patchsets: > > > 1.fsdax-rmap: > > > https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ > > > 2.fsdax-reflink: > > > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ > > > > > > Changes since v13 of fsdax-rmap: > > > 1. Fixed mistakes during rebasing code to latest next- > > > 2. Rebased to next-20220504 > > > > > > Changes since v10 of fsdax-reflink: > > > 1. Rebased to next-20220504 and fsdax-rmap > > > 2. Dropped a needless cleanup patch: 'fsdax: Convert dax_iomap_zero to > > > iter model' > > > 3. Fixed many conflicts during rebasing > > > 4. Fixed a dedupe bug in Patch 05: the actuall length to compare could > > > be > > > shorter than smap->length or dmap->length. > > > PS: There are many changes during rebasing. I think it's better to > > > review again. > > > > > > == > > > Shiyang Ruan (14): > > > fsdax-rmap: > > > dax: Introduce holder for dax_device > > > mm: factor helpers for memory_failure_dev_pagemap > > > pagemap,pmem: Introduce ->memory_failure() > > > fsdax: Introduce dax_lock_mapping_entry() > > > mm: Introduce mf_dax_kill_procs() for fsdax case > > > > Hmm. This patchset touches at least the dax, pagecache, and xfs > > subsystems. Assuming it's too late for 5.19, how should we stage this > > for 5.20? > > Yeah, it's past my "last date for this merge cycle" which was > -rc6. I expected stuff might slip a little - as it has with the LARP > code - but I don't have the time and bandwidth to start working > on merging another feature from scratch before the merge window > comes around. > > Getting the dax+reflink stuff in this cycle was always an optimistic > stretch, but I wanted to try so that there was no doubt it would be > ready for merge in the next cycle... > > > I could just add the entire series to iomap-5.20-merge and base the > > xfs-5.20-merge off of that? But I'm not sure what else might be landing > > in the other subsystems, so I'm open to input. > > It'll need to be a stable branch somewhere, but I don't think it > really matters where al long as it's merged into the xfs for-next > tree so it gets filesystem test coverage... So how about let the notify_failure() bits go through -mm this cycle, if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 baseline to build from?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 05:03:52PM -0700, Darrick J. Wong wrote: > On Sun, May 08, 2022 at 10:36:06PM +0800, Shiyang Ruan wrote: > > This is a combination of two patchsets: > > 1.fsdax-rmap: > > https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ > > 2.fsdax-reflink: > > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ > > > > Changes since v13 of fsdax-rmap: > > 1. Fixed mistakes during rebasing code to latest next- > > 2. Rebased to next-20220504 > > > > Changes since v10 of fsdax-reflink: > > 1. Rebased to next-20220504 and fsdax-rmap > > 2. Dropped a needless cleanup patch: 'fsdax: Convert dax_iomap_zero to > > iter model' > > 3. Fixed many conflicts during rebasing > > 4. Fixed a dedupe bug in Patch 05: the actuall length to compare could be > > shorter than smap->length or dmap->length. > > PS: There are many changes during rebasing. I think it's better to > > review again. > > > > == > > Shiyang Ruan (14): > > fsdax-rmap: > > dax: Introduce holder for dax_device > > mm: factor helpers for memory_failure_dev_pagemap > > pagemap,pmem: Introduce ->memory_failure() > > fsdax: Introduce dax_lock_mapping_entry() > > mm: Introduce mf_dax_kill_procs() for fsdax case > > Hmm. This patchset touches at least the dax, pagecache, and xfs > subsystems. Assuming it's too late for 5.19, how should we stage this > for 5.20? Yeah, it's past my "last date for this merge cycle" which was -rc6. I expected stuff might slip a little - as it has with the LARP code - but I don't have the time and bandwidth to start working on merging another feature from scratch before the merge window comes around. Getting the dax+reflink stuff in this cycle was always an optimistic stretch, but I wanted to try so that there was no doubt it would be ready for merge in the next cycle... > I could just add the entire series to iomap-5.20-merge and base the > xfs-5.20-merge off of that? But I'm not sure what else might be landing > in the other subsystems, so I'm open to input. It'll need to be a stable branch somewhere, but I don't think it really matters where al long as it's merged into the xfs for-next tree so it gets filesystem test coverage... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 06:55:50PM -0700, Dan Williams wrote: > [ add Andrew ] > > > On Tue, May 10, 2022 at 6:49 PM Dave Chinner wrote: > > > > On Tue, May 10, 2022 at 05:03:52PM -0700, Darrick J. Wong wrote: > > > On Sun, May 08, 2022 at 10:36:06PM +0800, Shiyang Ruan wrote: > > > > This is a combination of two patchsets: > > > > 1.fsdax-rmap: > > > > https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ > > > > 2.fsdax-reflink: > > > > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ > > > > > > > > Changes since v13 of fsdax-rmap: > > > > 1. Fixed mistakes during rebasing code to latest next- > > > > 2. Rebased to next-20220504 > > > > > > > > Changes since v10 of fsdax-reflink: > > > > 1. Rebased to next-20220504 and fsdax-rmap > > > > 2. Dropped a needless cleanup patch: 'fsdax: Convert dax_iomap_zero to > > > > iter model' > > > > 3. Fixed many conflicts during rebasing > > > > 4. Fixed a dedupe bug in Patch 05: the actuall length to compare > > > > could be > > > > shorter than smap->length or dmap->length. > > > > PS: There are many changes during rebasing. I think it's better to > > > > review again. > > > > > > > > == > > > > Shiyang Ruan (14): > > > > fsdax-rmap: > > > > dax: Introduce holder for dax_device > > > > mm: factor helpers for memory_failure_dev_pagemap > > > > pagemap,pmem: Introduce ->memory_failure() > > > > fsdax: Introduce dax_lock_mapping_entry() > > > > mm: Introduce mf_dax_kill_procs() for fsdax case > > > > > > Hmm. This patchset touches at least the dax, pagecache, and xfs > > > subsystems. Assuming it's too late for 5.19, how should we stage this > > > for 5.20? > > > > Yeah, it's past my "last date for this merge cycle" which was > > -rc6. I expected stuff might slip a little - as it has with the LARP > > code - but I don't have the time and bandwidth to start working > > on merging another feature from scratch before the merge window > > comes around. > > > > Getting the dax+reflink stuff in this cycle was always an optimistic > > stretch, but I wanted to try so that there was no doubt it would be > > ready for merge in the next cycle... > > > > > I could just add the entire series to iomap-5.20-merge and base the > > > xfs-5.20-merge off of that? But I'm not sure what else might be landing > > > in the other subsystems, so I'm open to input. > > > > It'll need to be a stable branch somewhere, but I don't think it > > really matters where al long as it's merged into the xfs for-next > > tree so it gets filesystem test coverage... > > So how about let the notify_failure() bits go through -mm this cycle, > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > baseline to build from? Sure, if you want to push them that way I'm not going to complain or stop you. :) Anything that makes the eventual XFS feature merge simpler counts as a win in my books. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH v11.1 06/07] xfs: support CoW in fsdax mode
In fsdax mode, WRITE and ZERO on a shared extent need CoW performed.
After that, new allocated extents needs to be remapped to the file.
So, add a CoW identification in ->iomap_begin(), and implement
->iomap_end() to do the remapping work.
Signed-off-by: Shiyang Ruan
Reviewed-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
---
fs/xfs/xfs_file.c | 33 -
fs/xfs/xfs_iomap.c | 30 +-
fs/xfs/xfs_iomap.h | 1 +
3 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index af954a5b71f8..fe9f92586acf 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -25,6 +25,7 @@
#include "xfs_iomap.h"
#include "xfs_reflink.h"
+#include
#include
#include
#include
@@ -669,7 +670,7 @@ xfs_file_dax_write(
pos = iocb->ki_pos;
trace_xfs_file_dax_write(iocb, from);
- ret = dax_iomap_rw(iocb, from, &xfs_direct_write_iomap_ops);
+ ret = dax_iomap_rw(iocb, from, &xfs_dax_write_iomap_ops);
if (ret > 0 && iocb->ki_pos > i_size_read(inode)) {
i_size_write(inode, iocb->ki_pos);
error = xfs_setfilesize(ip, pos, ret);
@@ -1254,6 +1255,31 @@ xfs_file_llseek(
return vfs_setpos(file, offset, inode->i_sb->s_maxbytes);
}
+#ifdef CONFIG_FS_DAX
+int
+xfs_dax_fault(
+ struct vm_fault *vmf,
+ enum page_entry_sizepe_size,
+ boolwrite_fault,
+ pfn_t *pfn)
+{
+ return dax_iomap_fault(vmf, pe_size, pfn, NULL,
+ (write_fault && !vmf->cow_page) ?
+ &xfs_dax_write_iomap_ops :
+ &xfs_read_iomap_ops);
+}
+#else
+int
+xfs_dax_fault(
+ struct vm_fault *vmf,
+ enum page_entry_sizepe_size,
+ boolwrite_fault,
+ pfn_t *pfn)
+{
+ return 0;
+}
+#endif
+
/*
* Locking for serialisation of IO during page faults. This results in a lock
* ordering of:
@@ -1285,10 +1311,7 @@ __xfs_filemap_fault(
pfn_t pfn;
xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
- ret = dax_iomap_fault(vmf, pe_size, &pfn, NULL,
- (write_fault && !vmf->cow_page) ?
-&xfs_direct_write_iomap_ops :
-&xfs_read_iomap_ops);
+ ret = xfs_dax_fault(vmf, pe_size, write_fault, &pfn);
if (ret & VM_FAULT_NEEDDSYNC)
ret = dax_finish_sync_fault(vmf, pe_size, pfn);
xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 5a393259a3a3..4c07f5e718fb 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -773,7 +773,8 @@ xfs_direct_write_iomap_begin(
/* may drop and re-acquire the ilock */
error = xfs_reflink_allocate_cow(ip, &imap, &cmap, &shared,
- &lockmode, flags & IOMAP_DIRECT);
+ &lockmode,
+ (flags & IOMAP_DIRECT) || IS_DAX(inode));
if (error)
goto out_unlock;
if (shared)
@@ -867,6 +868,33 @@ const struct iomap_ops xfs_direct_write_iomap_ops = {
.iomap_begin= xfs_direct_write_iomap_begin,
};
+static int
+xfs_dax_write_iomap_end(
+ struct inode*inode,
+ loff_t pos,
+ loff_t length,
+ ssize_t written,
+ unsignedflags,
+ struct iomap*iomap)
+{
+ struct xfs_inode*ip = XFS_I(inode);
+
+ if (!xfs_is_cow_inode(ip))
+ return 0;
+
+ if (!written) {
+ xfs_reflink_cancel_cow_range(ip, pos, length, true);
+ return 0;
+ }
+
+ return xfs_reflink_end_cow(ip, pos, written);
+}
+
+const struct iomap_ops xfs_dax_write_iomap_ops = {
+ .iomap_begin= xfs_direct_write_iomap_begin,
+ .iomap_end = xfs_dax_write_iomap_end,
+};
+
static int
xfs_buffered_write_iomap_begin(
struct inode*inode,
diff --git a/fs/xfs/xfs_iomap.h b/fs/xfs/xfs_iomap.h
index e88dc162c785..c782e8c0479c 100644
--- a/fs/xfs/xfs_iomap.h
+++ b/fs/xfs/xfs_iomap.h
@@ -51,5 +51,6 @@ extern const struct iomap_ops xfs_direct_write_iomap_ops;
extern const struct iomap_ops xfs_read_iomap_ops;
extern const struct iomap_ops xfs_seek_iomap_ops;
extern const struct iomap_ops xfs_xattr_iomap_ops;
+extern const struct iomap_ops xfs_dax_write_iomap_ops;
#endif /* __XFS_IOMAP_H__*/
--
2.35.1
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, 10 May 2022 18:55:50 -0700 Dan Williams wrote: > > It'll need to be a stable branch somewhere, but I don't think it > > really matters where al long as it's merged into the xfs for-next > > tree so it gets filesystem test coverage... > > So how about let the notify_failure() bits go through -mm this cycle, > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > baseline to build from? What are we referring to here? I think a minimal thing would be the memremap.h and memory-failure.c changes from https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? Sure, I can scoot that into 5.19-rc1 if you think that's best. It would probably be straining things to slip it into 5.19. The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the right thing, but it's a networking errno. I suppose livable with if it never escapes the kernel, but if it can get back to userspace then a user would be justified in wondering how the heck a filesystem operation generated a networking errno?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > wrote: > > > > It'll need to be a stable branch somewhere, but I don't think it > > > really matters where al long as it's merged into the xfs for-next > > > tree so it gets filesystem test coverage... > > > > So how about let the notify_failure() bits go through -mm this cycle, > > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > > baseline to build from? > > What are we referring to here? I think a minimal thing would be the > memremap.h and memory-failure.c changes from > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > would probably be straining things to slip it into 5.19. > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > right thing, but it's a networking errno. I suppose livable with if it > never escapes the kernel, but if it can get back to userspace then a > user would be justified in wondering how the heck a filesystem > operation generated a networking errno? most filesystems return EOPNOTSUPP rather enthusiastically when they don't know how to do something... --D
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 7:29 PM Andrew Morton wrote: > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > wrote: > > > > It'll need to be a stable branch somewhere, but I don't think it > > > really matters where al long as it's merged into the xfs for-next > > > tree so it gets filesystem test coverage... > > > > So how about let the notify_failure() bits go through -mm this cycle, > > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > > baseline to build from? > > What are we referring to here? I think a minimal thing would be the > memremap.h and memory-failure.c changes from > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? Latest is here: https://lore.kernel.org/all/20220508143620.1775214-1-ruansy.f...@fujitsu.com/ > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > would probably be straining things to slip it into 5.19. Hmm, if it's straining things and XFS will also target v5.20 I think the best course for all involved is just wait. Let some of the current conflicts in -mm land in v5.19 and then I can merge the DAX baseline and publish a stable branch for XFS and BTRFS to build upon for v5.20. > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > right thing, but it's a networking errno. I suppose livable with if it > never escapes the kernel, but if it can get back to userspace then a > user would be justified in wondering how the heck a filesystem > operation generated a networking errno?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 09:20:57PM -0700, Dan Williams wrote: > On Tue, May 10, 2022 at 7:29 PM Andrew Morton > wrote: > > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > wrote: > > > > > > It'll need to be a stable branch somewhere, but I don't think it > > > > really matters where al long as it's merged into the xfs for-next > > > > tree so it gets filesystem test coverage... > > > > > > So how about let the notify_failure() bits go through -mm this cycle, > > > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > > > baseline to build from? > > > > What are we referring to here? I think a minimal thing would be the > > memremap.h and memory-failure.c changes from > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? > > Latest is here: > https://lore.kernel.org/all/20220508143620.1775214-1-ruansy.f...@fujitsu.com/ > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > would probably be straining things to slip it into 5.19. > > Hmm, if it's straining things and XFS will also target v5.20 I think > the best course for all involved is just wait. Let some of the current > conflicts in -mm land in v5.19 and then I can merge the DAX baseline > and publish a stable branch for XFS and BTRFS to build upon for v5.20. Sounds good to /me... --D > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > right thing, but it's a networking errno. I suppose livable with if it > > never escapes the kernel, but if it can get back to userspace then a > > user would be justified in wondering how the heck a filesystem > > operation generated a networking errno?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" wrote: > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > wrote: > > > > > > It'll need to be a stable branch somewhere, but I don't think it > > > > really matters where al long as it's merged into the xfs for-next > > > > tree so it gets filesystem test coverage... > > > > > > So how about let the notify_failure() bits go through -mm this cycle, > > > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > > > baseline to build from? > > > > What are we referring to here? I think a minimal thing would be the > > memremap.h and memory-failure.c changes from > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > would probably be straining things to slip it into 5.19. > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > right thing, but it's a networking errno. I suppose livable with if it > > never escapes the kernel, but if it can get back to userspace then a > > user would be justified in wondering how the heck a filesystem > > operation generated a networking errno? > > most filesystems return EOPNOTSUPP rather enthusiastically when > they don't know how to do something... Can it propagate back to userspace?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote: > On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" > wrote: > > > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > > wrote: > > > > > > > > It'll need to be a stable branch somewhere, but I don't think it > > > > > really matters where al long as it's merged into the xfs for-next > > > > > tree so it gets filesystem test coverage... > > > > > > > > So how about let the notify_failure() bits go through -mm this cycle, > > > > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > > > > baseline to build from? > > > > > > What are we referring to here? I think a minimal thing would be the > > > memremap.h and memory-failure.c changes from > > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com > > > ? > > > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > > would probably be straining things to slip it into 5.19. > > > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > > right thing, but it's a networking errno. I suppose livable with if it > > > never escapes the kernel, but if it can get back to userspace then a > > > user would be justified in wondering how the heck a filesystem > > > operation generated a networking errno? > > > > most filesystems return EOPNOTSUPP rather enthusiastically when > > they don't know how to do something... > > Can it propagate back to userspace? Maybe not this one, but the point Darrick is making is that we really don't care if it does because we've been propagating it to userspace in documented filesystem APIs for at least 15 years now. e.g: $ man 2 fallocate . Errors . EOPNOTSUPP The filesystem containing the file referred to by fd does not support this operation; or the mode is not supported by the filesystem containing the file referred to by fd. . Other random examples: pwritev2(RWF_NOWAIT) can return -EOPNOTSUPP on buffered writes. Documented in the man page. FICLONERANGE on an filesystem that doesn't support reflink will return -EOPNOTSUPP. Documented in the man page. mmap(MAP_SYNC) returns -EOPNOTSUPP if the underlying filesystem and/or storage doesn't support DAX. Documented in the man page. I could go on, but I think I've made the point already... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
