From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Shiyang Ruan <ruansy.fnst@cn.fujitsu.com>
Cc: linux-xfs@vger.kernel.org, linux-nvdimm@lists.01.org,
darrick.wong@oracle.com, hch@infradead.org, david@fromorbit.com,
linux-kernel@vger.kernel.org, gujx@cn.fujitsu.com,
qi.fuli@fujitsu.com, caoj.fnst@cn.fujitsu.com
Subject: Re: [RFC PATCH v2 0/7] xfs: reflink & dedupe for fsdax (read/write path).
Date: Wed, 30 Oct 2019 06:48:18 -0500 [thread overview]
Message-ID: <20191030114818.emvmgfgqadiqintw@fiona> (raw)
In-Reply-To: <20191030041358.14450-1-ruansy.fnst@cn.fujitsu.com>
On 12:13 30/10, Shiyang Ruan wrote:
> This patchset aims to take care of this issue to make reflink and dedupe
> work correctly (actually in read/write path, there still has some problems,
> such as the page->mapping and page->index issue, in mmap path) in XFS under
> fsdax mode.
Have you managed to solve the problem of multi-mapped pages? I don't
think we can include this until we solve that problem. This is the
problem I faced when I was doing the btrfs dax support.
Suppose there is an extent shared with multiple files. You map data for
both files. Which inode should page->mapping->host (precisely
page->mapping) point to? As Dave pointed out, this needs to be fixed at
the mm level, and will not only benefit dax with CoW but other
areas such as overlayfs and possibly containers.
--
Goldwyn
>
> It is based on Goldwyn's patchsets: "v4 Btrfs dax support" and the latest
> iomap. I borrowed some patches related and made a few fix to make it
> basically works fine.
>
> For dax framework:
> 1. adapt to the latest change in iomap (two iomaps).
>
> For XFS:
> 1. distinguish dax write/zero from normal write/zero.
> 2. remap extents after COW.
> 3. add file contents comparison function based on dax framework.
> 4. use xfs_break_layouts() instead of break_layout to support dax.
>
>
> Goldwyn Rodrigues (3):
> dax: replace mmap entry in case of CoW
> fs: dedup file range to use a compare function
> dax: memcpy before zeroing range
>
> Shiyang Ruan (4):
> dax: Introduce dax_copy_edges() for COW.
> dax: copy data before write.
> xfs: handle copy-on-write in fsdax write() path.
> xfs: support dedupe for fsdax.
>
> fs/btrfs/ioctl.c | 3 +-
> fs/dax.c | 211 +++++++++++++++++++++++++++++++++++++----
> fs/iomap/buffered-io.c | 8 +-
> fs/ocfs2/file.c | 2 +-
> fs/read_write.c | 11 ++-
> fs/xfs/xfs_bmap_util.c | 6 +-
> fs/xfs/xfs_file.c | 10 +-
> fs/xfs/xfs_iomap.c | 3 +-
> fs/xfs/xfs_iops.c | 11 ++-
> fs/xfs/xfs_reflink.c | 79 ++++++++-------
> include/linux/dax.h | 16 ++--
> include/linux/fs.h | 9 +-
> 12 files changed, 291 insertions(+), 78 deletions(-)
>
> --
> 2.23.0
>
>
>
--
Goldwyn
next prev parent reply other threads:[~2019-10-30 11:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 4:13 Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 1/7] dax: Introduce dax_copy_edges() for COW Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 2/7] dax: copy data before write Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 3/7] dax: replace mmap entry in case of CoW Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 4/7] fs: dedup file range to use a compare function Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 5/7] dax: memcpy before zeroing range Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 6/7] xfs: handle copy-on-write in fsdax write() path Shiyang Ruan
2019-10-30 4:13 ` [RFC PATCH v2 7/7] xfs: support dedupe for fsdax Shiyang Ruan
2019-10-30 11:48 ` Goldwyn Rodrigues [this message]
2019-10-31 4:54 ` [RFC PATCH v2 0/7] xfs: reflink & dedupe for fsdax (read/write path) Shiyang Ruan
2019-11-08 3:10 ` Shiyang Ruan
2019-11-08 3:30 ` Dan Williams
2019-11-14 20:24 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191030114818.emvmgfgqadiqintw@fiona \
--to=rgoldwyn@suse.de \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=gujx@cn.fujitsu.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=qi.fuli@fujitsu.com \
--cc=ruansy.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®