lkml.org 
[lkml]   [2022]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
[ add Andrew ]


On Tue, May 10, 2022 at 6:49 PM Dave Chinner <david@fromorbit.com> 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.fnst@fujitsu.com/
> > > 2.fsdax-reflink: https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.fnst@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?

\
 
 \ /
  Last update: 2022-05-11 03:57    [W:1.776 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site