On Tue, Jun 29, 2021 at 11:25:37AM +, ruansy.f...@fujitsu.com wrote:
>
>
> > -Original Message-
> > From: Darrick J. Wong
> > Subject: Re: [PATCH v6.1 6/7] fs/xfs: Handle CoW for fsdax write() path
> >
> > On Mon, Jun 28, 2021 at 02:55:03AM
On Thu, Jun 24, 2021 at 08:49:17AM +, ruansy.f...@fujitsu.com wrote:
> Hi Darrick,
>
> Do you have any comment on this?
Sorry, was on vacation.
> Thanks,
> Ruan.
>
> > -Original Message-
> > From: Shiyang Ruan
> > Subject: [PATCH v6.1 6/7] fs/xfs: Handle CoW for fsdax write() path
On Mon, Jul 05, 2021 at 09:21:53PM +0800, Gao Xiang wrote:
> DAX is quite useful for some VM use cases in order to save guest
> memory extremely with minimal lightweight EROFS.
>
> In order to prepare for such use cases, add preliminary dax support
> for non-tailpacking regular files for now.
>
On Mon, Jun 28, 2021 at 02:55:03AM +, ruansy.f...@fujitsu.com wrote:
> > -Original Message-
> > Subject: Re: [PATCH v6.1 6/7] fs/xfs: Handle CoW for fsdax write() path
> >
> > On Thu, Jun 24, 2021 at 08:49:17AM +, ruansy.f...@fujitsu.com wrote:
> > > Hi Darrick,
> > >
> > > Do you
On Tue, Aug 17, 2021 at 11:08:40PM -0700, Jane Chu wrote:
>
> On 8/17/2021 10:43 PM, Jane Chu wrote:
> > More information -
> >
> > On 8/16/2021 10:20 AM, Jane Chu wrote:
> > > Hi, ShiYang,
> > >
> > > So I applied the v6 patch series to my 5.14-rc3 as it's what you
> > > indicated is what v6
y: Christoph Hellwig
> > Reviewed-by: Dan Williams
> > ---
> > fs/xfs/xfs_super.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
>
> Darrick, any concerns with me taking this through the dax tree?
Nope.
Reviewed-by: Darrick J. Won
On Mon, Aug 09, 2021 at 08:12:18AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> include/linux/iomap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/iomap
On Mon, Aug 09, 2021 at 08:12:19AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> include/linux/iomap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/iomap
On Mon, Aug 09, 2021 at 08:12:33AM +0200, Christoph Hellwig wrote:
> Rewrite the ->bmap implementation based on iomap_iter.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/iomap/fiemap.c | 31 +--
> 1 file changed, 13 insertions(+), 18 deletions(-)
>
> diff --git
On Tue, Aug 10, 2021 at 08:10:47AM +1000, Dave Chinner wrote:
> On Mon, Aug 09, 2021 at 08:12:25AM +0200, Christoph Hellwig wrote:
> > The iomap_iter struct provides a convenient way to package up and
> > maintain all the arguments to the various mapping and operation
> > functions. It is
On Mon, Aug 09, 2021 at 08:12:30AM +0200, Christoph Hellwig wrote:
> Switch iomap_page_mkwrite to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 39 +--
>
On Mon, Aug 09, 2021 at 08:12:35AM +0200, Christoph Hellwig wrote:
> Rewrite iomap_seek_data to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Nice cleanup,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/seek.c | 47 ---
&g
On Mon, Aug 09, 2021 at 08:12:37AM +0200, Christoph Hellwig wrote:
> Switch the dax_iomap_rw implementation to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
/me gets excited about this file getting cleaned up
Reviewed-by: Darrick J. Wong
--D
> ---
>
Reviewed-by: Darrick J. Wong
--D
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/iomap/buffered-io.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 44587209e6d7c7..26e16cc9d44931 1006
On Mon, Aug 09, 2021 at 08:12:29AM +0200, Christoph Hellwig wrote:
> Switch iomap_zero_range to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Straightforward.
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 36 ++--
&g
On Mon, Aug 09, 2021 at 08:12:32AM +0200, Christoph Hellwig wrote:
> Rewrite the ->fiemap implementation based on iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Nice cleanups!
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/i
On Mon, Aug 09, 2021 at 08:12:27AM +0200, Christoph Hellwig wrote:
> Switch iomap_file_buffered_write to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Seems pretty straightforward.
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buf
On Mon, Aug 09, 2021 at 08:12:28AM +0200, Christoph Hellwig wrote:
> Switch iomap_file_unshare to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 35 ++-
> 1 file chan
On Mon, Aug 09, 2021 at 08:12:34AM +0200, Christoph Hellwig wrote:
> Rewrite iomap_seek_hole to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Looks good to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/seek.c | 51 +---
+ * function must be called in a loop that continues as long it returns a
> + * positive value. If 0 or a negative value is returned, the caller must not
> + * return to the loop body. Within a loop body, there are two ways to break
> out
> + * of the loop body: leave @iter.processed unc
On Mon, Aug 09, 2021 at 08:12:36AM +0200, Christoph Hellwig wrote:
> Switch iomap_swapfile_activate to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
Smooth
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/swapfile.c | 38 --
&g
On Mon, Aug 09, 2021 at 08:12:26AM +0200, Christoph Hellwig wrote:
> Switch the page cache read functions to use iomap_iter instead of
> iomap_apply.
>
> Signed-off-by: Christoph Hellwig
Looks reasonable,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/
On Mon, Aug 09, 2021 at 08:12:31AM +0200, Christoph Hellwig wrote:
> Switch __iomap_dio_rw to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
I like the reduction in ->submit_io arguments. The conversion seems
straightforward enough.
Reviewed-by: Darrick J. Wong
--D
>
On Thu, Aug 12, 2021 at 08:49:14AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 11, 2021 at 12:17:08PM -0700, Darrick J. Wong wrote:
> > > iter.c is also my preference, but in the end I don't care too much.
> >
> > Ok. My plan for this is to change this patch
On Mon, Jul 19, 2021 at 12:34:53PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series replies the existing callback-based iomap_apply to an iter based
> model. The prime aim here is to simply the DAX reflink support, which
Jan Kara pointed out that recent gcc and clang support a magic
atthew Wilcox .
Signed-off-by: Christoph Hellwig
[djwong: add to apply.c to preserve git history of iomap loop control]
Reviewed-by: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
fs/iomap/apply.c | 74 -
fs/iomap/trace.h
From: Christoph Hellwig
iomap_apply is unused now, so remove it.
Signed-off-by: Christoph Hellwig
[djwong: rebase this patch to preserve git history of iomap loop control]
Reviewed-by: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
fs/iomap/apply.c | 91
From: Christoph Hellwig
Rewrite the ->bmap implementation based on iomap_iter.
Signed-off-by: Christoph Hellwig
[djwong: restructure the loop to make its behavior a little clearer]
Reviewed-by: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
fs/iomap/fiemap.c |
From: Darrick J. Wong
Now that we've moved iomap to the iterator model, rename this file to be
in sync with the functions contained inside of it.
Signed-off-by: Darrick J. Wong
---
fs/iomap/Makefile |2 +-
fs/iomap/iter.c |0
2 files changed, 1 insertion(+), 1 deletion(-)
rename
On Wed, Aug 11, 2021 at 07:38:56AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 10, 2021 at 05:31:18PM -0700, Darrick J. Wong wrote:
> > > +static inline void iomap_iter_done(struct iomap_iter *iter)
> >
> > I wonder why this is a separate function, since it only ha
> Does this still happen with this series:
>
> https://lore.kernel.org/linux-block/2021092217.2453343-1-...@lst.de/T/#m8dc646a4dfc40f443227da6bb1c77d9daec524db
>
> ?
My test machinse all hit this when writeback throttling is enabled, so
Tested-by: Darrick J. Wong
--D
On Tue, Sep 28, 2021 at 06:34:26AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 27, 2021 at 04:02:59PM -0700, Darrick J. Wong wrote:
> > > > Looping xfstests generic/108 or xfs/279 on mountpoints with fsdax
> > > > enabled can lead to panic like this:
> >
On Tue, Sep 28, 2021 at 07:17:00AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 27, 2021 at 10:16:10PM -0700, Darrick J. Wong wrote:
> > > > My test machinse all hit this when writeback throttling is enabled, so
> > > >
> > > > Tested-by: Darrick J. Wo
From: Darrick J. Wong
It's totally silly that the dax zero_page_range implementations are
required to accept a page count, but one of the four implementations
silently ignores the page count and the wrapper itself errors out if you
try to do more than one page.
Fix the nvdimm implementation
On Thu, Dec 09, 2021 at 07:11:19AM +0100, Christoph Hellwig wrote:
> On Wed, Dec 08, 2021 at 04:55:59PM -0800, Darrick J. Wong wrote:
> > Ok, so ... I don't know what I'm supposed to apply this to? Is this
> > something that should go in Christoph's development branch?
>
s: c6f40468657d ("fsdax: decouple zeroing from the iomap buffered I/O
> code")
> Reported-by: Dan Carpenter
> Signed-off-by: Christoph Hellwig
Looks good,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
On Wed, Dec 08, 2021 at 04:48:46PM -0800, Darrick J. Wong wrote:
> On Wed, Dec 08, 2021 at 10:12:03AM +0100, Christoph Hellwig wrote:
> > bytes also hold the return value from iomap_write_end, which can contain
> > a negative error value. As bytes is always less than the
ing the page in, but if nobody /else/ has any
objection or imminently wants to use the iomap argument, then...
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/gfs2/bmap.c | 5 ++---
> fs/iomap/buffered-io.c | 6 +++---
> include/linux/iomap.h | 5 ++---
> 3 files changed, 7
On Mon, Jul 19, 2021 at 12:35:19PM +0200, Christoph Hellwig wrote:
> Avoid the open coded calls to ->iomap_begin and ->iomap_end and call
> iomap_iter instead.
>
> Signed-off-by: Christoph Hellwig
Finally this nightmare is over...
Reviewed-by: Darrick J. Wong
--D
>
map/trace.h | 40 -
> include/linux/iomap.h | 10 -
> 4 files changed, 150 deletions(-)
mmm, negative LOC delta ;)
Reviewed-by: Darrick J. Wong
--D
> delete mode 100644 fs/iomap/apply.c
>
> diff --git a/fs/iomap/Makefile b/fs/iomap/Makefile
> index 85034deb5
On Mon, Jul 19, 2021 at 12:35:15PM +0200, Christoph Hellwig wrote:
> Pass the iomap_iter structure instead of individual parameters to
> various internal helpers for buffered I/O.
>
> Signed-off-by: Christoph Hellwig
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/i
ine that for such a simple function it can
probably tell that we don't change *iomap.
IMHO, constifiying functions is a good way to signal to /programmers/
that they're not intended to touch the arguments, so
Reviewed-by: Darrick J. Wong
--D
> ---
> include/linux/iomap.h | 3 +--
> 1 file changed, 1 ins
On Mon, Jul 19, 2021 at 12:35:10PM +0200, Christoph Hellwig wrote:
> Rewrite iomap_seek_hole to use iomap_iter.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/iomap/seek.c | 46 +++---
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git
On Mon, Jul 19, 2021 at 12:35:09PM +0200, Christoph Hellwig wrote:
> Rewrite the ->bmap implementation based on iomap_iter.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/iomap/fiemap.c | 31 +--
> 1 file changed, 13 insertions(+), 18 deletions(-)
>
> diff --git
On Mon, Jul 19, 2021 at 12:35:00PM +0200, Christoph Hellwig wrote:
> iomap_read_page_sync never modifies the passed in iomap, so mark
> it const.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 2 +-
> 1 file chang
On Mon, Jul 19, 2021 at 12:34:57PM +0200, Christoph Hellwig wrote:
> __block_write_begin_int never modifies the passed in iomap, so mark it
> const.
>
> Signed-off-by: Christoph Hellwig
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/buffer.c | 4 ++--
> fs/int
On Mon, Jul 19, 2021 at 12:34:59PM +0200, Christoph Hellwig wrote:
> iomap_read_inline_data never modifies the passed in iomap, so mark
> it const.
>
> Signed-off-by: Christoph Hellwig
Looks good,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 2 +-
&g
On Mon, Jul 19, 2021 at 12:34:58PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
LGTM
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index da41f9363
LGTM!
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 32
> include/linux/iomap.h | 2 +-
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index eb5d742b5bf8
On Mon, Jul 19, 2021 at 12:35:01PM +0200, Christoph Hellwig wrote:
> The iomap_iter struct provides a convenient way to package up and
> maintain all the arguments to the various mapping and operation
> functions. It is operated on using the iomap_iter() function that
> is called in loop until
t; @@ -511,10 +511,6 @@ iomap_migrate_page(struct address_space *mapping, struct
> page *newpage,
> EXPORT_SYMBOL_GPL(iomap_migrate_page);
> #endif /* CONFIG_MIGRATION */
>
> -enum {
> - IOMAP_WRITE_F_UNSHARE = (1 << 0),
> -};
Oh good, this
On Mon, Jul 19, 2021 at 12:34:54PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/trace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/iomap/trace.h b/fs/iomap/trace.h
>
On Mon, Jul 19, 2021 at 12:34:53PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series replies the existing callback-based iomap_apply to an iter based
> model. The prime aim here is to simply the DAX reflink support, which
> requires iterating through two inodes, something that is rather
On Tue, Jul 27, 2021 at 08:31:38AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 26, 2021 at 09:39:22AM -0700, Darrick J. Wong wrote:
> > The documentation needs to be much more explicit about the fact that you
> > cannot "break;" your way out of an iomap_iter loop. I thi
On Mon, Jul 26, 2021 at 10:22:36AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 19, 2021 at 10:22:47AM -0700, Darrick J. Wong wrote:
> > > -static loff_t
> > > -iomap_seek_hole_actor(struct inode *inode, loff_t start, loff_t length,
> > > - void *dat
On Mon, Jul 26, 2021 at 10:19:42AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 19, 2021 at 10:05:45AM -0700, Darrick J. Wong wrote:
> > > bno = 0;
> > > - ret = iomap_apply(inode, pos, blocksize, 0, ops, ,
> > > - iomap_bmap_actor);
> >
On Mon, Jan 10, 2022 at 09:42:15PM +, Matthew Wilcox wrote:
> I know these requests usually come from Darrick, and we had intended
> that they would come that route. Between the holidays and various
> things which Darrick needed to work on, he asked if I could send the
> pull request
all files and processes(not only the current progress)
> are handled correctly. Also drop the cache of associated files before
> pmem is removed.
>
> [1]:
> https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.st...@dwillia2-desk3.amr.corp.intel.com/
>
On Thu, Sep 28, 2023 at 09:20:52AM -0700, Andrew Morton wrote:
> On Thu, 28 Sep 2023 16:44:00 +0800 Shiyang Ruan
> wrote:
>
> > But please pick the following patch[1] as well, which fixes failures of
> > xfs55[0-2] cases.
> >
> > [1]
> >
On Wed, Sep 27, 2023 at 11:18:42AM +1000, Dave Chinner wrote:
> On Tue, Sep 26, 2023 at 07:55:19AM -0700, Darrick J. Wong wrote:
> > On Thu, Sep 21, 2023 at 04:33:04PM +0800, Shiyang Ruan wrote:
> > > Hi,
> > >
> > > Any comments?
> >
> > I n
On Thu, Sep 21, 2023 at 04:33:04PM +0800, Shiyang Ruan wrote:
> Hi,
>
> Any comments?
I notice that xfs/55[0-2] still fail on my fakepmem machine:
--- /tmp/fstests/tests/xfs/550.out 2023-09-23 09:40:47.839521305 -0700
+++ /var/tmp/fstests/xfs/550.out.bad2023-09-24 20:00:23.4
On Fri, Sep 29, 2023 at 11:28:02AM -0700, Dan Williams wrote:
> Eric Sandeen wrote:
> > On 9/29/23 9:17 AM, Chandan Babu R wrote:
> > > On Thu, Sep 28, 2023 at 09:20:52 AM -0700, Andrew Morton wrote:
> > >> On Thu, 28 Sep 2023 16:44:00 +0800 Shiyang Ruan
> > >> wrote:
> > >>
> > >>> But please
On Mon, Oct 02, 2023 at 06:09:56PM +0530, Chandan Babu R wrote:
> On Mon, Oct 02, 2023 at 08:15:57 PM +0800, Shiyang Ruan wrote:
> > 在 2023/9/30 2:34, Dan Williams 写道:
> >> Shiyang Ruan wrote:
> >>>
> >>>
> >>> 在 2023/9/29 1:13, Darrick J. Wo
On Tue, Oct 10, 2023 at 11:53:02AM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/10/10 0:47, Darrick J. Wong 写道:
> > On Mon, Oct 09, 2023 at 10:14:12PM +0800, Shiyang Ruan wrote:
> > >
> > >
> > > 在 2023/10/6 0:05, Darrick J. Wong 写道:
> > > >
On Mon, Oct 09, 2023 at 10:14:12PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/10/6 0:05, Darrick J. Wong 写道:
> > On Thu, Oct 05, 2023 at 04:53:12PM +0800, Shiyang Ruan wrote:
> > >
> > >
> > > 在 2023/10/5 8:08, Darrick J. Wong 写道:
> > > > &g
s and processes(not only the current progress)
> > are handled correctly. Also drop the cache of associated files before
> > pmem is removed.
> >
> > [1]:
> > https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.st...@dwillia2-desk3.amr.corp.intel.com
On Thu, Oct 05, 2023 at 04:53:12PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/10/5 8:08, Darrick J. Wong 写道:
> > > >
> > > > Sorry, I sent the list below to Chandan, didn't cc the maillist
> > > > because it's just a rough list rather than a PR:
&g
On Wed, Aug 23, 2023 at 04:17:06PM +0800, Shiyang Ruan wrote:
>
> Changes since v12:
> 1. correct flag name in subject (MF_MEM_REMOVE => MF_MEM_PRE_REMOVE)
> 2. complete the behavior when fs has already frozen by kernel call
> NOTICE: Instead of "call notify_failure() again w/o
On Thu, Aug 24, 2023 at 05:41:50PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/8/24 7:36, Darrick J. Wong 写道:
> > On Wed, Aug 23, 2023 at 04:17:06PM +0800, Shiyang Ruan wrote:
> > >
> > > Changes since v12:
> > > 1. correct flag name in subject (MF_
On Fri, Aug 25, 2023 at 11:52:35AM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/8/25 7:57, Darrick J. Wong 写道:
> > On Thu, Aug 24, 2023 at 05:41:50PM +0800, Shiyang Ruan wrote:
> > >
> > >
> > > 在 2023/8/24 7:36, Darrick J. Wong 写道:
> > > >
On Thu, Mar 23, 2023 at 02:50:38PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/3/23 7:03, Andrew Morton 写道:
> > On Wed, 22 Mar 2023 11:11:09 + Shiyang Ruan
> > wrote:
> >
> > > unshare copies data from source to destination. But if the source is
> > > HOLE or UNWRITTEN extents, we should zero
total length.
>
> Fixes: 0e79e3736d54 ("fsdax: dedupe: iter two files at the same time")
> Signed-off-by: Shiyang Ruan
Makese sense,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --
On Tue, Apr 25, 2023 at 03:23:15PM +0200, Jan Kara wrote:
> On Tue 25-04-23 20:47:35, Shiyang Ruan wrote:
> >
> >
> > 在 2023/4/20 20:09, Jan Kara 写道:
> > > On Thu 20-04-23 10:07:39, Shiyang Ruan wrote:
> > > > 在 2023/4/12 18:52, Shiyang Ruan 写道:
> > > > > This is a RFC HOTFIX.
> > > > >
> > > >
On Wed, Apr 26, 2023 at 10:27:43AM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/4/25 23:18, Darrick J. Wong 写道:
> > On Tue, Apr 25, 2023 at 03:23:15PM +0200, Jan Kara wrote:
> > > On Tue 25-04-23 20:47:35, Shiyang Ruan wrote:
> > > >
> > > >
> >
On Tue, Mar 28, 2023 at 09:41:46AM +, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
On Thu, Apr 06, 2023 at 06:50:22PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/4/5 1:45, Darrick J. Wong 写道:
> > On Tue, Mar 28, 2023 at 09:41:46AM +, Shiyang Ruan wrote:
> > > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > > dev_pagemap_failu
On Fri, Jul 14, 2023 at 05:07:58PM +0800, Shiyang Ruan wrote:
> Hi Darrick,
>
> Thanks for applying the 1st patch.
>
> Now, since this patch is based on the new freeze_super()/thaw_super()
> api[1], I'd like to ask what's the plan for this api? It seems to have
> missed the v6.5-rc1.
>
> [1]
On Mon, Jul 31, 2023 at 05:36:36PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/7/29 23:15, Darrick J. Wong 写道:
> > On Thu, Jun 29, 2023 at 04:16:51PM +0800, Shiyang Ruan wrote:
> > > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > > dev
On Sat, Jul 29, 2023 at 06:01:00PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/7/20 9:50, Shiyang Ruan 写道:
> >
> >
> > 在 2023/7/14 22:18, Darrick J. Wong 写道:
> > > On Fri, Jul 14, 2023 at 05:07:58PM +0800, Shiyang Ruan wrote:
> > > > Hi Darrick,
&g
On Thu, Jun 29, 2023 at 04:16:51PM +0800, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> on it to unmap all files in use, and
On Thu, Jan 11, 2024 at 10:59:21AM -0600, Bill O'Donnell wrote:
> On Fri, Sep 15, 2023 at 02:38:54PM +0800, Shiyang Ruan wrote:
> > FSDAX and reflink can work together now, let's drop this warning.
> >
> > Signed-off-by: Shiyang Ruan
>
> Are there any updates on this?
Remind us to slip this
On Fri, Sep 15, 2023 at 02:38:54PM +0800, Shiyang Ruan wrote:
> FSDAX and reflink can work together now, let's drop this warning.
>
> Signed-off-by: Shiyang Ruan
Chandan: Can we get this queued up for 6.8, please? This has been a
loong time coming.
Reviewed-by: Darrick J. W
82 matches
Mail list logo
