Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2024/2/27 0:58, Dan Williams 写道: Shiyang Ruan wrote: 在 2024/1/12 10:21, Darrick J. Wong 写道: 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 in for 6.8-rc7 if nobody complains about the new dax functionality. :) Hi, I have been running tests on weekly -rc release, and so far the fsdax functionality looks good. So, I'd like to send this remind since the -rc7 is not far away. Please let me know if you have any concerns. Ruan, thanks for all your effort on this! It's my pleasure. Thank you all also for your patience and kind guidance. You all helped me a lot. ヽ(^▽^)ノ -- Ruan. [..] --- fs/xfs/xfs_super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 1f77014c6e1a..faee773fa026 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -371,7 +371,6 @@ xfs_setup_dax_always( return -EINVAL; } - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own risk"); return 0; Acked-by: Dan Williams
Re: [PATCH] xfs: drop experimental warning for FSDAX
Shiyang Ruan wrote: > > > 在 2024/1/12 10:21, Darrick J. Wong 写道: > > 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 in for 6.8-rc7 if nobody complains about the new > > dax functionality. :) > > Hi, > > I have been running tests on weekly -rc release, and so far the fsdax > functionality looks good. So, I'd like to send this remind since the > -rc7 is not far away. Please let me know if you have any concerns. Ruan, thanks for all your effort on this! [..] > >>> --- > >>> fs/xfs/xfs_super.c | 1 - > >>> 1 file changed, 1 deletion(-) > >>> > >>> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > >>> index 1f77014c6e1a..faee773fa026 100644 > >>> --- a/fs/xfs/xfs_super.c > >>> +++ b/fs/xfs/xfs_super.c > >>> @@ -371,7 +371,6 @@ xfs_setup_dax_always( > >>> return -EINVAL; > >>> } > >>> > >>> - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own > >>> risk"); > >>> return 0; Acked-by: Dan Williams
Re: [PATCH] xfs: drop experimental warning for FSDAX
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. Wong --D > --- > fs/xfs/xfs_super.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 1f77014c6e1a..faee773fa026 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -371,7 +371,6 @@ xfs_setup_dax_always( > return -EINVAL; > } > > - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own > risk"); > return 0; > > disable_dax: > -- > 2.42.0 >
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2024/1/12 10:21, Darrick J. Wong 写道: 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 in for 6.8-rc7 if nobody complains about the new dax functionality. :) Hi, I have been running tests on weekly -rc release, and so far the fsdax functionality looks good. So, I'd like to send this remind since the -rc7 is not far away. Please let me know if you have any concerns. -- Thanks, Ruan. --D Thanks- Bill --- fs/xfs/xfs_super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 1f77014c6e1a..faee773fa026 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -371,7 +371,6 @@ xfs_setup_dax_always( return -EINVAL; } - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own risk"); return 0; disable_dax: -- 2.42.0
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 in for 6.8-rc7 if nobody complains about the new dax functionality. :) --D > Thanks- > Bill > > > > --- > > fs/xfs/xfs_super.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > > index 1f77014c6e1a..faee773fa026 100644 > > --- a/fs/xfs/xfs_super.c > > +++ b/fs/xfs/xfs_super.c > > @@ -371,7 +371,6 @@ xfs_setup_dax_always( > > return -EINVAL; > > } > > > > - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own > > risk"); > > return 0; > > > > disable_dax: > > -- > > 2.42.0 > > > >
Re: [PATCH] xfs: drop experimental warning for FSDAX
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? Thanks- Bill > --- > fs/xfs/xfs_super.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 1f77014c6e1a..faee773fa026 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -371,7 +371,6 @@ xfs_setup_dax_always( > return -EINVAL; > } > > - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own > risk"); > return 0; > > disable_dax: > -- > 2.42.0 >
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 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:
> > > > > > > >
> > > > > > > >
> > > > > > > > 1. subject: [v3] xfs: correct calculation for agend and
> > > > > > > > blockcount
> > > > > > > > url:
> > > > > > > >
> > > > > > > > https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
> > > > > > > > note:This one is a fix patch for commit: 5cf32f63b0f4
> > > > > > > > ("xfs:
> > > > > > > > fix the calculation for "end" and "length"").
> > > > > > > >It can solve the fail of xfs/55[0-2]: the
> > > > > > > > programs
> > > > > > > >accessing the DAX file may not be notified as
> > > > > > > > expected,
> > > > > > > > because the length always 1 block less than
> > > > > > > > actual. Then
> > > > > > > > this patch fixes this.
> > > > > > > >
> > > > > > > >
> > > > > > > > 2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE
> > > > > > > > for unbind
> > > > > > > > url:
> > > > > > > >
> > > > > > > > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
> > > > > > > > note:This is a feature patch. It handles the
> > > > > > > > pre-remove event
> > > > > > > > of DAX device, by notifying kernel/user space before
> > > > > > > > actually
> > > > > > > > removing.
> > > > > > > >It has been picked by Andrew in his
> > > > > > > >mm-hotfixes-unstable. I am not sure whether you
> > > > > > > > or he will
> > > > > > > > merge this one.
> > > > > > > >
> > > > > > > >
> > > > > > > > 3. subject: [v1] xfs: drop experimental warning for FSDAX
> > > > > > > > url:
> > > > > > > >
> > > > > > > > https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
> > > > > > > > note:With the patches mentioned above, I did a lot of
> > > > > > > > tests,
> > > > > > > > including xfstests and blackbox tests, the FSDAX function
> > > > > > > > looks
> > > > > > > > good now. So I think the experimental warning could be
> > > > > > > > dropped.
> > > > > > >
> > > > > > > Darrick/Dave, Could you please review the above patch and let us
> > > > > > > know if you
> > > > > > > have any objections?
> > > > > >
> > > > > > The first two patches are ok. The third one ... well I was about
> > > > > > to say
> > > > > > ok but then this happened with generic/269 on a 6.6-rc4 kernel and
> > > > > > those
> > > > > > two patches applied:
> > > > >
> > > > > Hi Darrick,
> > > > >
> > > > > Thanks for testing. I just tested this case (generic/269) on
> > > > > v6.6-rc4 with
> > > > > my 3 patches again, but it didn't fail. Such WARNING message didn't
> > > > > show in
> > > > > dmesg too.
> > > > >
> > > > > My local.config is shown as below:
> > > > > [nodax_reflink]
> > > > > export FSTYP=xfs
> > > > > export TEST_DEV=/dev/pmem0
> > > > > export TEST_DIR=/mnt/test
> > > > > export SCRATCH_DEV=/dev/pmem1
> > > > > export SCRATCH_MNT=/mnt/scratch
> > > > > export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
> > > > >
> > > > > [dax_reflink]
> > > > > export FSTYP=xfs
> > > > > export TEST_DEV=/dev/pmem0
> > > > > export TEST_DIR=/mnt/test
> > > > > export SCRATCH_DEV=/dev/pmem1
> > > > > export SCRATCH_MNT=/mnt/scratch
> > > > > export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
> > > > > export MOUNT_OPTIONS="-o dax"
> > > > > export TEST_FS_MOUNT_OPTS="-o dax"
> > > > >
> > > > > And tools version are:
> > > > >- xfstests (v2023.09.03)
> > > >
> > > > Same here.
> > > >
> > > > >- xfsprogs (v6.4.0)
> > > >
> > > > I have a newer branch, though it only contains resyncs with newer kernel
> > > > versions and bugfixes.
> > > >
> > > > > Could you show me more info (such as kernel config, local.config) ?
> > > > > So that
> > > > > I can find out what exactly is going wrong.
> > > >
> > > > The full xml output from fstests is here:
> > > >
> > > > https://djwong.org/fstests/output/.fa9f295c6a2dd4426aa26b4d74e8e0299ad2307507547d5444c157f0e883df92/.2e718425eda716ad848ae05dfab82a670af351f314e26b3cb658a929331bf2eb/result.xml
> > > >
> > > > I think the key difference between your setup and mine is that
> > > > MKFS_OPTIONS includes '-d daxinherit=1' and MOUNT_OPTIONS do not include
> > > > -o dax. That shouldn't make any difference, though.
>
> A little strange thing I found:
> According to the result.xml, the MKFS_OPTIONS did
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 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 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:
1. subject: [v3] xfs: correct calculation for agend and blockcount
url:
https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs:
fix the calculation for "end" and "length"").
It can solve the fail of xfs/55[0-2]: the programs
accessing the DAX file may not be notified as expected,
because the length always 1 block less than actual. Then
this patch fixes this.
2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
url:
https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
note:This is a feature patch. It handles the pre-remove event
of DAX device, by notifying kernel/user space before actually
removing.
It has been picked by Andrew in his
mm-hotfixes-unstable. I am not sure whether you or he will
merge this one.
3. subject: [v1] xfs: drop experimental warning for FSDAX
url:
https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
note:With the patches mentioned above, I did a lot of tests,
including xfstests and blackbox tests, the FSDAX function looks
good now. So I think the experimental warning could be dropped.
Darrick/Dave, Could you please review the above patch and let us know if you
have any objections?
The first two patches are ok. The third one ... well I was about to say
ok but then this happened with generic/269 on a 6.6-rc4 kernel and those
two patches applied:
Hi Darrick,
Thanks for testing. I just tested this case (generic/269) on v6.6-rc4 with
my 3 patches again, but it didn't fail. Such WARNING message didn't show in
dmesg too.
My local.config is shown as below:
[nodax_reflink]
export FSTYP=xfs
export TEST_DEV=/dev/pmem0
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/pmem1
export SCRATCH_MNT=/mnt/scratch
export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
[dax_reflink]
export FSTYP=xfs
export TEST_DEV=/dev/pmem0
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/pmem1
export SCRATCH_MNT=/mnt/scratch
export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
export MOUNT_OPTIONS="-o dax"
export TEST_FS_MOUNT_OPTS="-o dax"
And tools version are:
- xfstests (v2023.09.03)
Same here.
- xfsprogs (v6.4.0)
I have a newer branch, though it only contains resyncs with newer kernel
versions and bugfixes.
Could you show me more info (such as kernel config, local.config) ? So that
I can find out what exactly is going wrong.
The full xml output from fstests is here:
https://djwong.org/fstests/output/.fa9f295c6a2dd4426aa26b4d74e8e0299ad2307507547d5444c157f0e883df92/.2e718425eda716ad848ae05dfab82a670af351f314e26b3cb658a929331bf2eb/result.xml
I think the key difference between your setup and mine is that
MKFS_OPTIONS includes '-d daxinherit=1' and MOUNT_OPTIONS do not include
-o dax. That shouldn't make any difference, though.
A little strange thing I found:
According to the result.xml, the MKFS_OPTIONS didn't include -m rmapbt=1:
mkfs.xfs will turn on reflink by default, but won't turn on rmapbt.
Then xfs/55[0-2] should be "not run" because they have
_require_xfs_scratch_rmapbt.
Also, this alert message didn't show in my tests:
[ 6047.876110] XFS (pmem1): xlog_verify_grant_tail: space >
BBTOB(tail_blocks)
But I don't think it is related.
Also: In the weeks leading up to me adding the PREREMOVE patches a
couple of days ago, no test (generic/269 or otherwise) hit that ASSERT.
Has it failed again since this time? If so, please sent me the
result.xml because it is needed for analyze. Thank you~
I'm wondering if that means that the preremove code isn't shooting down
a page mapping or something?
Grepping through the result.xml reveals:
$ grep -E '(generic.269|xfs.55[012])' /tmp/result.xml
563:
910:
1685:
1686:
1689:[ 6046.844058] run fstests generic/269 at 2023-10-04 15:26:57
2977:
So it's possible that 550 or 552 messed this up for us. :/
See attached kconfig.
Thanks for the info. I tried to make my environment same as yours, but
still couldn't reproduce the fail. I also let xfs/550 & xfs/552 ran before
generic/269.
[root@f38 xfst]# ./check -s nodax_reflink -r xfs/550 xfs/552 generic/269
SECTION -- nodax_reflink
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 f38 6.6.0-rc4 #365 SMP PREEMPT_DYNAMIC Sun Oct
8 15:19:36 CST 2023
MKFS_OPTIONS -- -f -m reflink=1,rmapbt=1 -d daxinherit=1 /dev/pmem1
MOUNT_OP
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 写道:
> > > > > >
> > > > > > Sorry, I sent the list below to Chandan, didn't cc the maillist
> > > > > > because it's just a rough list rather than a PR:
> > > > > >
> > > > > >
> > > > > > 1. subject: [v3] xfs: correct calculation for agend and blockcount
> > > > > > url:
> > > > > >
> > > > > > https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
> > > > > > note:This one is a fix patch for commit: 5cf32f63b0f4
> > > > > > ("xfs:
> > > > > > fix the calculation for "end" and "length"").
> > > > > > It can solve the fail of xfs/55[0-2]: the programs
> > > > > > accessing the DAX file may not be notified as
> > > > > > expected,
> > > > > > because the length always 1 block less than actual.
> > > > > > Then
> > > > > > this patch fixes this.
> > > > > >
> > > > > >
> > > > > > 2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for
> > > > > > unbind
> > > > > > url:
> > > > > >
> > > > > > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
> > > > > > note:This is a feature patch. It handles the pre-remove
> > > > > > event
> > > > > > of DAX device, by notifying kernel/user space before actually
> > > > > > removing.
> > > > > > It has been picked by Andrew in his
> > > > > > mm-hotfixes-unstable. I am not sure whether you or he
> > > > > > will
> > > > > > merge this one.
> > > > > >
> > > > > >
> > > > > > 3. subject: [v1] xfs: drop experimental warning for FSDAX
> > > > > > url:
> > > > > >
> > > > > > https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
> > > > > > note:With the patches mentioned above, I did a lot of
> > > > > > tests,
> > > > > > including xfstests and blackbox tests, the FSDAX function looks
> > > > > > good now. So I think the experimental warning could be dropped.
> > > > >
> > > > > Darrick/Dave, Could you please review the above patch and let us know
> > > > > if you
> > > > > have any objections?
> > > >
> > > > The first two patches are ok. The third one ... well I was about to say
> > > > ok but then this happened with generic/269 on a 6.6-rc4 kernel and those
> > > > two patches applied:
> > >
> > > Hi Darrick,
> > >
> > > Thanks for testing. I just tested this case (generic/269) on v6.6-rc4
> > > with
> > > my 3 patches again, but it didn't fail. Such WARNING message didn't show
> > > in
> > > dmesg too.
> > >
> > > My local.config is shown as below:
> > > [nodax_reflink]
> > > export FSTYP=xfs
> > > export TEST_DEV=/dev/pmem0
> > > export TEST_DIR=/mnt/test
> > > export SCRATCH_DEV=/dev/pmem1
> > > export SCRATCH_MNT=/mnt/scratch
> > > export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
> > >
> > > [dax_reflink]
> > > export FSTYP=xfs
> > > export TEST_DEV=/dev/pmem0
> > > export TEST_DIR=/mnt/test
> > > export SCRATCH_DEV=/dev/pmem1
> > > export SCRATCH_MNT=/mnt/scratch
> > > export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
> > > export MOUNT_OPTIONS="-o dax"
> > > export TEST_FS_MOUNT_OPTS="-o dax"
> > >
> > > And tools version are:
> > > - xfstests (v2023.09.03)
> >
> > Same here.
> >
> > > - xfsprogs (v6.4.0)
> >
> > I have a newer branch, though it only contains resyncs with newer kernel
> > versions and bugfixes.
> >
> > > Could you show me more info (such as kernel config, local.config) ? So
> > > that
> > > I can find out what exactly is going wrong.
> >
> > The full xml output from fstests is here:
> >
> > https://djwong.org/fstests/output/.fa9f295c6a2dd4426aa26b4d74e8e0299ad2307507547d5444c157f0e883df92/.2e718425eda716ad848ae05dfab82a670af351f314e26b3cb658a929331bf2eb/result.xml
> >
> > I think the key difference between your setup and mine is that
> > MKFS_OPTIONS includes '-d daxinherit=1' and MOUNT_OPTIONS do not include
> > -o dax. That shouldn't make any difference, though.
> >
> > Also: In the weeks leading up to me adding the PREREMOVE patches a
> > couple of days ago, no test (generic/269 or otherwise) hit that ASSERT.
> > I'm wondering if that means that the preremove code isn't shooting down
> > a page mapping or something?
> >
> > Grepping through the result.xml reveals:
> >
> > $ grep -E '(generic.269|xfs.55[012])' /tmp/result.xml
> > 563:
> > 910:
> > 1685:
> > 1686:
> > 1689:[ 6046.844058] run fstests generic/269 at 2023-10-04 15:26:57
> > 2977:
> >
> > So it's possible that 550 or 552 messed this up for us. :/
> >
> > See attached kconfig.
>
> Thanks for the info. I tried to make my environment same as yours, but
> still couldn't reproduce the fail. I also let xfs/550 & xfs/552 ra
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 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 写道:
Sorry, I sent the list below to Chandan, didn't cc the maillist
because it's just a rough list rather than a PR:
1. subject: [v3] xfs: correct calculation for agend and blockcount
url:
https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs:
fix the calculation for "end" and "length"").
It can solve the fail of xfs/55[0-2]: the programs
accessing the DAX file may not be notified as expected,
because the length always 1 block less than actual. Then
this patch fixes this.
2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
url:
https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
note:This is a feature patch. It handles the pre-remove event
of DAX device, by notifying kernel/user space before actually
removing.
It has been picked by Andrew in his
mm-hotfixes-unstable. I am not sure whether you or he will
merge this one.
3. subject: [v1] xfs: drop experimental warning for FSDAX
url:
https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
note:With the patches mentioned above, I did a lot of tests,
including xfstests and blackbox tests, the FSDAX function looks
good now. So I think the experimental warning could be dropped.
Darrick/Dave, Could you please review the above patch and let us know if you
have any objections?
The first two patches are ok. The third one ... well I was about to say
ok but then this happened with generic/269 on a 6.6-rc4 kernel and those
two patches applied:
Hi Darrick,
Thanks for testing. I just tested this case (generic/269) on v6.6-rc4 with
my 3 patches again, but it didn't fail. Such WARNING message didn't show in
dmesg too.
My local.config is shown as below:
[nodax_reflink]
export FSTYP=xfs
export TEST_DEV=/dev/pmem0
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/pmem1
export SCRATCH_MNT=/mnt/scratch
export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
[dax_reflink]
export FSTYP=xfs
export TEST_DEV=/dev/pmem0
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/pmem1
export SCRATCH_MNT=/mnt/scratch
export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
export MOUNT_OPTIONS="-o dax"
export TEST_FS_MOUNT_OPTS="-o dax"
And tools version are:
- xfstests (v2023.09.03)
Same here.
- xfsprogs (v6.4.0)
I have a newer branch, though it only contains resyncs with newer kernel
versions and bugfixes.
Could you show me more info (such as kernel config, local.config) ? So that
I can find out what exactly is going wrong.
The full xml output from fstests is here:
https://djwong.org/fstests/output/.fa9f295c6a2dd4426aa26b4d74e8e0299ad2307507547d5444c157f0e883df92/.2e718425eda716ad848ae05dfab82a670af351f314e26b3cb658a929331bf2eb/result.xml
I think the key difference between your setup and mine is that
MKFS_OPTIONS includes '-d daxinherit=1' and MOUNT_OPTIONS do not include
-o dax. That shouldn't make any difference, though.
Also: In the weeks leading up to me adding the PREREMOVE patches a
couple of days ago, no test (generic/269 or otherwise) hit that ASSERT.
I'm wondering if that means that the preremove code isn't shooting down
a page mapping or something?
Grepping through the result.xml reveals:
$ grep -E '(generic.269|xfs.55[012])' /tmp/result.xml
563:
910:
1685:
1686:
1689:[ 6046.844058] run fstests generic/269 at 2023-10-04 15:26:57
2977:
So it's possible that 550 or 552 messed this up for us. :/
See attached kconfig.
Thanks for the info. I tried to make my environment same as yours, but
still couldn't reproduce the fail. I also let xfs/550 & xfs/552 ran
before generic/269.
[root@f38 xfst]# ./check -s nodax_reflink -r xfs/550 xfs/552 generic/269
SECTION -- nodax_reflink
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 f38 6.6.0-rc4 #365 SMP PREEMPT_DYNAMIC Sun
Oct 8 15:19:36 CST 2023
MKFS_OPTIONS -- -f -m reflink=1,rmapbt=1 -d daxinherit=1 /dev/pmem1
MOUNT_OPTIONS -- -o usrquota,grpquota,prjquota, /dev/pmem1 /mnt/scratch
xfs/550 2s ... 2s
xfs/552 2s ... 1s
generic/269 22s ... 23s
Ran: xfs/550 xfs/552 generic/269
Passed all 3 tests
SECTION -- nodax_reflink
=
Ran: xfs/550 xfs/552 generic/269
Passed all 3 tests
And xfs/269 is testing fsstress & dd on a scratch device at the same
time. It won't reach the PREREMOVE code or xfs' notify failure code.
I'd like to know what your git tree looks like, is it *v6.6-rc4 + my
patches only* ? Does it contain other patches?
--
Thanks,
Ruan.
--D
--
Thanks,
Ruan.
Re: [PATCH] xfs: drop experimental warning for FSDAX
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:
> > > >
> > > >
> > > > 1. subject: [v3] xfs: correct calculation for agend and blockcount
> > > > url:
> > > >
> > > > https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
> > > > note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs:
> > > > fix the calculation for "end" and "length"").
> > > > It can solve the fail of xfs/55[0-2]: the programs
> > > > accessing the DAX file may not be notified as expected,
> > > > because the length always 1 block less than actual. Then
> > > >this patch fixes this.
> > > >
> > > >
> > > > 2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
> > > > url:
> > > >
> > > > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
> > > > note:This is a feature patch. It handles the pre-remove event
> > > > of DAX device, by notifying kernel/user space before actually
> > > >removing.
> > > > It has been picked by Andrew in his
> > > > mm-hotfixes-unstable. I am not sure whether you or he will
> > > > merge this one.
> > > >
> > > >
> > > > 3. subject: [v1] xfs: drop experimental warning for FSDAX
> > > > url:
> > > >
> > > > https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
> > > > note:With the patches mentioned above, I did a lot of tests,
> > > > including xfstests and blackbox tests, the FSDAX function looks
> > > >good now. So I think the experimental warning could be dropped.
> > >
> > > Darrick/Dave, Could you please review the above patch and let us know if
> > > you
> > > have any objections?
> >
> > The first two patches are ok. The third one ... well I was about to say
> > ok but then this happened with generic/269 on a 6.6-rc4 kernel and those
> > two patches applied:
>
> Hi Darrick,
>
> Thanks for testing. I just tested this case (generic/269) on v6.6-rc4 with
> my 3 patches again, but it didn't fail. Such WARNING message didn't show in
> dmesg too.
>
> My local.config is shown as below:
> [nodax_reflink]
> export FSTYP=xfs
> export TEST_DEV=/dev/pmem0
> export TEST_DIR=/mnt/test
> export SCRATCH_DEV=/dev/pmem1
> export SCRATCH_MNT=/mnt/scratch
> export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
>
> [dax_reflink]
> export FSTYP=xfs
> export TEST_DEV=/dev/pmem0
> export TEST_DIR=/mnt/test
> export SCRATCH_DEV=/dev/pmem1
> export SCRATCH_MNT=/mnt/scratch
> export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
> export MOUNT_OPTIONS="-o dax"
> export TEST_FS_MOUNT_OPTS="-o dax"
>
> And tools version are:
> - xfstests (v2023.09.03)
Same here.
> - xfsprogs (v6.4.0)
I have a newer branch, though it only contains resyncs with newer kernel
versions and bugfixes.
> Could you show me more info (such as kernel config, local.config) ? So that
> I can find out what exactly is going wrong.
The full xml output from fstests is here:
https://djwong.org/fstests/output/.fa9f295c6a2dd4426aa26b4d74e8e0299ad2307507547d5444c157f0e883df92/.2e718425eda716ad848ae05dfab82a670af351f314e26b3cb658a929331bf2eb/result.xml
I think the key difference between your setup and mine is that
MKFS_OPTIONS includes '-d daxinherit=1' and MOUNT_OPTIONS do not include
-o dax. That shouldn't make any difference, though.
Also: In the weeks leading up to me adding the PREREMOVE patches a
couple of days ago, no test (generic/269 or otherwise) hit that ASSERT.
I'm wondering if that means that the preremove code isn't shooting down
a page mapping or something?
Grepping through the result.xml reveals:
$ grep -E '(generic.269|xfs.55[012])' /tmp/result.xml
563:
910:
1685:
1686:
1689:[ 6046.844058] run fstests generic/269 at 2023-10-04 15:26:57
2977:
So it's possible that 550 or 552 messed this up for us. :/
See attached kconfig.
--D
>
>
> --
> Thanks,
> Ruan.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 6.6.0-rc4 djw:djwx Kernel
#
CONFIG_CC_VERSION_TEXT="x86_64-linux-gnu-gcc (Ubuntu 12.3.0-1ubuntu1~22.04)
12.3.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=120300
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=23800
CONFIG_LD_IS_BFD=y
CONFIG_LD_VERSION=23800
CONFIG_LLD_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
CONFIG_TOOLS_SUPPORT_RELR=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
CONFIG_PAHOLE_VERSION=125
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_WERROR is not set
CONFIG_LOCALV
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 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:
1. subject: [v3] xfs: correct calculation for agend and blockcount
url:
https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs:
fix the calculation for "end" and "length"").
It can solve the fail of xfs/55[0-2]: the programs
accessing the DAX file may not be notified as expected,
because the length always 1 block less than actual. Then
this patch fixes this.
2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
url:
https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
note:This is a feature patch. It handles the pre-remove event
of DAX device, by notifying kernel/user space before actually
removing.
It has been picked by Andrew in his
mm-hotfixes-unstable. I am not sure whether you or he will
merge this one.
3. subject: [v1] xfs: drop experimental warning for FSDAX
url:
https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
note:With the patches mentioned above, I did a lot of tests,
including xfstests and blackbox tests, the FSDAX function looks
good now. So I think the experimental warning could be dropped.
Darrick/Dave, Could you please review the above patch and let us know if you
have any objections?
The first two patches are ok. The third one ... well I was about to say
ok but then this happened with generic/269 on a 6.6-rc4 kernel and those
two patches applied:
Hi Darrick,
Thanks for testing. I just tested this case (generic/269) on v6.6-rc4
with my 3 patches again, but it didn't fail. Such WARNING message
didn't show in dmesg too.
My local.config is shown as below:
[nodax_reflink]
export FSTYP=xfs
export TEST_DEV=/dev/pmem0
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/pmem1
export SCRATCH_MNT=/mnt/scratch
export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
[dax_reflink]
export FSTYP=xfs
export TEST_DEV=/dev/pmem0
export TEST_DIR=/mnt/test
export SCRATCH_DEV=/dev/pmem1
export SCRATCH_MNT=/mnt/scratch
export MKFS_OPTIONS="-m reflink=1,rmapbt=1"
export MOUNT_OPTIONS="-o dax"
export TEST_FS_MOUNT_OPTS="-o dax"
And tools version are:
- xfstests (v2023.09.03)
- xfsprogs (v6.4.0)
Could you show me more info (such as kernel config, local.config) ? So
that I can find out what exactly is going wrong.
--
Thanks,
Ruan.
Re: [PATCH] xfs: drop experimental warning for FSDAX
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. Wong 写道:
> 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]
> >> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com
> >
> > I guess I can take that xfs patch, as it fixes a DAX patch. I hope the
> > xfs team
> > are watching.
> >
> > But
> >
> > a) I'm not subscribed to linux-xfs and
> >
> > b) the changelog fails to describe the userspace-visible effects of
> > the bug, so I (and others) are unable to determine which kernel
> > versions should be patched.
> >
> > Please update that changelog and resend?
>
> That's a purely xfs patch anyways. The correct maintainer is Chandan,
> not Andrew.
>
> /me notes that post-reorg, patch authors need to ask the release manager
> (Chandan) directly to merge their patches after they've gone through
> review. Pull requests of signed tags are encouraged strongly.
>
> Shiyang, could you please send Chandan pull requests with /all/ the
> relevant pmem patches incorporated? I think that's one PR for the
> "xfs: correct calculation for agend and blockcount" for 6.6; and a
> second PR with all the non-bugfix stuff (PRE_REMOVE and whatnot) for
> 6.7.
> >>>
> >>> OK. Though I don't know how to send the PR by email, I have sent a list
> >>> of the patches and added description for each one.
> >> If you want I can create a signed pull request from a git.kernel.org
> >> tree.
> >> Where is that list of patches? I see v15 of preremove.
> >
> > Sorry, I sent the list below to Chandan, didn't cc the maillist
> > because it's just a rough list rather than a PR:
> >
> >
> > 1. subject: [v3] xfs: correct calculation for agend and blockcount
> >url:
> >
> > https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
> >note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs:
> >fix the calculation for "end" and "length"").
> > It can solve the fail of xfs/55[0-2]: the programs
> > accessing the DAX file may not be notified as expected,
> >because the length always 1 block less than actual. Then
> > this patch fixes this.
> >
> >
> > 2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
> >url:
> >
> > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
> >note:This is a feature patch. It handles the pre-remove event
> >of DAX device, by notifying kernel/user space before actually
> > removing.
> > It has been picked by Andrew in his
> > mm-hotfixes-unstable. I am not sure whether you or he will
> >merge this one.
> >
> >
> > 3. subject: [v1] xfs: drop experimental warning for FSDAX
> >url:
> >
> > https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
> >note:With the patches mentioned above, I did a lot of tests,
> >including xfstests and blackbox tests, the FSDAX function looks
> > good now. So I think the experimental warning could be dropped.
>
> Darrick/Dave, Could you please review the above patch and let us know if you
> have any objections?
The first two patches are ok. The third one ... well I was about to say
ok but then this happened with generic/269 on a 6.6-rc4 kernel and those
two patches applied:
[ 6046.844058] run fstests generic/269 at 2023-10-04 15:26:57
[ 6047.479351] XFS (pmem0): Mounting V5 Filesystem
e9b327cb-ea4d-4cf8-8310-f7a2922ec934
[ 6047.487228] XFS (pmem0): Ending clean mount
[ 6047.663228] XFS (pmem1): Mounting V5 Filesystem
3c882433-356a-48d2-9670-65f09ab9da7e
[ 6047.669433] XFS (pmem1): Ending clean mount
[ 6047.671261] XFS (pmem1): Quotacheck needed: Please wait.
[ 6047.673825] XFS (pmem1): Quotacheck: Done.
[ 6047.876110] XFS (pmem1): xlog_verify_grant_tail: space > BBTOB(tail_blocks)
[ 6054.851738] [ cut here ]
[ 6054.852580] WARNING: CPU: 1 PID: 2221403 at fs/dax.c:372
dax_insert_entry+0x2b8/0x2f0
[ 6054.853924] Modules linked in: dm_snapshot dm_bufio dm_zero xfs btrfs
blake2b_generic xor lzo_compress lzo_decompress zlib_deflate raid6_pq
zstd_compress ext2 nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_tcpudp
ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac bfq ip_set
nf_tables libcrc32c nfnetlink pvpanic_mmio nd_pmem pvpanic nd_btt
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 pick the following patch[1] as well, which fixes failures of > > >>> xfs55[0-2] cases. > > >>> > > >>> [1] > > >>> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com > > >> > > >> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the > > >> xfs team > > >> are watching. > > >> > > >> But > > >> > > >> a) I'm not subscribed to linux-xfs and > > >> > > >> b) the changelog fails to describe the userspace-visible effects of > > >>the bug, so I (and others) are unable to determine which kernel > > >>versions should be patched. > > >> > > >> Please update that changelog and resend? > > > > > > I will apply "xfs: correct calculation for agend and blockcount" patch to > > > xfs-linux Git tree and include it for the next v6.6 pull request to Linus. > > > > > > At the outset, It looks like I can pick "mm, pmem, xfs: Introduce > > > MF_MEM_PRE_REMOVE for unbind" > > > (i.e. > > > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u) > > > patch for v6.7 as well. But that will require your Ack. Please let me know > > > your opinion. > > > > > > Also, I will pick "xfs: drop experimental warning for FSDAX" patch for > > > v6.7. > > > > While I hate to drag it out even longer, it seems slightly optimistic to > > drop experimental at the same time as the "last" fix, in case it's not > > really the last fix. > > > > But I don't have super strong feelings about it, and I would be happy to > > finally see experimental go away. So if those who are more tuned into > > the details are comfortable with that 6.7 plan, I'll defer to them on > > the question. > > The main blockage of "experimental" was the inability to specify > dax+reflink, and the concern that resolving that conflict would end up > breaking MAP_SYNC semantics or some other regression. > > The dax_notify_failure() work has resolved that conflict without > regressing semantics. > > Ultimately this is an XFS filesystem maintainer decision, but my > perspective is that v6.7-rc1 starts the clock on experimental going away > and if the bug reports stay quiet that state can persist into > v6.7-final. If new reports crop up, revert the experimental removal and > try again for v6.8. I'm ok with this. Let's merge the PRE_REMOVE patch (and the arithematic fix) for 6.7-rc1. If nobody screams during 6.7, send a patch to Linus removing EXPERIMENTAL after (say) 6.7-rc8. DAX will no longer be experimental for the 2024 LTS. --D
Re: [PATCH] xfs: drop experimental warning for FSDAX
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. Wong 写道:
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]
>> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com
>
> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the
> xfs team
> are watching.
>
> But
>
> a) I'm not subscribed to linux-xfs and
>
> b) the changelog fails to describe the userspace-visible effects of
> the bug, so I (and others) are unable to determine which kernel
> versions should be patched.
>
> Please update that changelog and resend?
That's a purely xfs patch anyways. The correct maintainer is Chandan,
not Andrew.
/me notes that post-reorg, patch authors need to ask the release manager
(Chandan) directly to merge their patches after they've gone through
review. Pull requests of signed tags are encouraged strongly.
Shiyang, could you please send Chandan pull requests with /all/ the
relevant pmem patches incorporated? I think that's one PR for the
"xfs: correct calculation for agend and blockcount" for 6.6; and a
second PR with all the non-bugfix stuff (PRE_REMOVE and whatnot) for
6.7.
>>>
>>> OK. Though I don't know how to send the PR by email, I have sent a list
>>> of the patches and added description for each one.
>> If you want I can create a signed pull request from a git.kernel.org
>> tree.
>> Where is that list of patches? I see v15 of preremove.
>
> Sorry, I sent the list below to Chandan, didn't cc the maillist
> because it's just a rough list rather than a PR:
>
>
> 1. subject: [v3] xfs: correct calculation for agend and blockcount
>url:
>
> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
>note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs:
>fix the calculation for "end" and "length"").
> It can solve the fail of xfs/55[0-2]: the programs
> accessing the DAX file may not be notified as expected,
>because the length always 1 block less than actual. Then
> this patch fixes this.
>
>
> 2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
>url:
>
> https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
>note:This is a feature patch. It handles the pre-remove event
>of DAX device, by notifying kernel/user space before actually
> removing.
> It has been picked by Andrew in his
> mm-hotfixes-unstable. I am not sure whether you or he will
>merge this one.
>
>
> 3. subject: [v1] xfs: drop experimental warning for FSDAX
>url:
>
> https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
>note:With the patches mentioned above, I did a lot of tests,
>including xfstests and blackbox tests, the FSDAX function looks
> good now. So I think the experimental warning could be dropped.
Darrick/Dave, Could you please review the above patch and let us know if you
have any objections?
--
Chandan
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2023/9/30 2:34, Dan Williams 写道:
Shiyang Ruan wrote:
在 2023/9/29 1:13, Darrick J. Wong 写道:
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]
https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com
I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs team
are watching.
But
a) I'm not subscribed to linux-xfs and
b) the changelog fails to describe the userspace-visible effects of
the bug, so I (and others) are unable to determine which kernel
versions should be patched.
Please update that changelog and resend?
That's a purely xfs patch anyways. The correct maintainer is Chandan,
not Andrew.
/me notes that post-reorg, patch authors need to ask the release manager
(Chandan) directly to merge their patches after they've gone through
review. Pull requests of signed tags are encouraged strongly.
Shiyang, could you please send Chandan pull requests with /all/ the
relevant pmem patches incorporated? I think that's one PR for the
"xfs: correct calculation for agend and blockcount" for 6.6; and a
second PR with all the non-bugfix stuff (PRE_REMOVE and whatnot) for
6.7.
OK. Though I don't know how to send the PR by email, I have sent a list
of the patches and added description for each one.
If you want I can create a signed pull request from a git.kernel.org
tree.
Where is that list of patches? I see v15 of preremove.
Sorry, I sent the list below to Chandan, didn't cc the maillist because
it's just a rough list rather than a PR:
1. subject: [v3] xfs: correct calculation for agend and blockcount
url:
https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com/
note:This one is a fix patch for commit: 5cf32f63b0f4 ("xfs: fix
the calculation for "end" and "length"").
It can solve the fail of xfs/55[0-2]: the programs
accessing the DAX file may not be notified as expected, because the
length always 1 block less than actual. Then this patch fixes this.
2. subject: [v15] mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
url:
https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u
note:This is a feature patch. It handles the pre-remove event
of DAX device, by notifying kernel/user space before actually removing.
It has been picked by Andrew in his mm-hotfixes-unstable. I
am not sure whether you or he will merge this one.
3. subject: [v1] xfs: drop experimental warning for FSDAX
url:
https://lore.kernel.org/linux-xfs/20230915063854.1784918-1-ruansy.f...@fujitsu.com/
note:With the patches mentioned above, I did a lot of tests,
including xfstests and blackbox tests, the FSDAX function looks good
now. So I think the experimental warning could be dropped.
--
Thanks,
Ruan.
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 pick the following patch[1] as well, which fixes failures of > >>> xfs55[0-2] cases. > >>> > >>> [1] > >>> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com > >> > >> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the > >> xfs team > >> are watching. > >> > >> But > >> > >> a) I'm not subscribed to linux-xfs and > >> > >> b) the changelog fails to describe the userspace-visible effects of > >>the bug, so I (and others) are unable to determine which kernel > >>versions should be patched. > >> > >> Please update that changelog and resend? > > > > I will apply "xfs: correct calculation for agend and blockcount" patch to > > xfs-linux Git tree and include it for the next v6.6 pull request to Linus. > > > > At the outset, It looks like I can pick "mm, pmem, xfs: Introduce > > MF_MEM_PRE_REMOVE for unbind" > > (i.e. > > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u) > > patch for v6.7 as well. But that will require your Ack. Please let me know > > your opinion. > > > > Also, I will pick "xfs: drop experimental warning for FSDAX" patch for v6.7. > > While I hate to drag it out even longer, it seems slightly optimistic to > drop experimental at the same time as the "last" fix, in case it's not > really the last fix. > > But I don't have super strong feelings about it, and I would be happy to > finally see experimental go away. So if those who are more tuned into > the details are comfortable with that 6.7 plan, I'll defer to them on > the question. The main blockage of "experimental" was the inability to specify dax+reflink, and the concern that resolving that conflict would end up breaking MAP_SYNC semantics or some other regression. The dax_notify_failure() work has resolved that conflict without regressing semantics. Ultimately this is an XFS filesystem maintainer decision, but my perspective is that v6.7-rc1 starts the clock on experimental going away and if the bug reports stay quiet that state can persist into v6.7-final. If new reports crop up, revert the experimental removal and try again for v6.8.
Re: [PATCH] xfs: drop experimental warning for FSDAX
Shiyang Ruan wrote: > > > 在 2023/9/29 1:13, Darrick J. Wong 写道: > > 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] > >>> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com > >> > >> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the > >> xfs team > >> are watching. > >> > >> But > >> > >> a) I'm not subscribed to linux-xfs and > >> > >> b) the changelog fails to describe the userspace-visible effects of > >> the bug, so I (and others) are unable to determine which kernel > >> versions should be patched. > >> > >> Please update that changelog and resend? > > > > That's a purely xfs patch anyways. The correct maintainer is Chandan, > > not Andrew. > > > > /me notes that post-reorg, patch authors need to ask the release manager > > (Chandan) directly to merge their patches after they've gone through > > review. Pull requests of signed tags are encouraged strongly. > > > > Shiyang, could you please send Chandan pull requests with /all/ the > > relevant pmem patches incorporated? I think that's one PR for the > > "xfs: correct calculation for agend and blockcount" for 6.6; and a > > second PR with all the non-bugfix stuff (PRE_REMOVE and whatnot) for > > 6.7. > > OK. Though I don't know how to send the PR by email, I have sent a list > of the patches and added description for each one. If you want I can create a signed pull request from a git.kernel.org tree. Where is that list of patches? I see v15 of preremove.
Re: [PATCH] xfs: drop experimental warning for FSDAX
On Fri, Sep 29, 2023 at 09:35:17 AM -0500, 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 pick the following patch[1] as well, which fixes failures of xfs55[0-2] cases. [1] https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com >>> >>> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs >>> team >>> are watching. >>> >>> But >>> >>> a) I'm not subscribed to linux-xfs and >>> >>> b) the changelog fails to describe the userspace-visible effects of >>>the bug, so I (and others) are unable to determine which kernel >>>versions should be patched. >>> >>> Please update that changelog and resend? >> >> I will apply "xfs: correct calculation for agend and blockcount" patch to >> xfs-linux Git tree and include it for the next v6.6 pull request to Linus. >> >> At the outset, It looks like I can pick "mm, pmem, xfs: Introduce >> MF_MEM_PRE_REMOVE for unbind" >> (i.e. >> https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u) >> patch for v6.7 as well. But that will require your Ack. Please let me know >> your opinion. >> >> Also, I will pick "xfs: drop experimental warning for FSDAX" patch for v6.7. > > While I hate to drag it out even longer, it seems slightly optimistic to > drop experimental at the same time as the "last" fix, in case it's not > really the last fix. > > But I don't have super strong feelings about it, and I would be happy to > finally see experimental go away. So if those who are more tuned into > the details are comfortable with that 6.7 plan, I'll defer to them on > the question. Sorry, I now realize that the patch doesn't yet have a Reviewed-by tag. I will pick the patch for v6.7 only if get its one. -- Chandan
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 pick the following patch[1] as well, which fixes failures of >>> xfs55[0-2] cases. >>> >>> [1] >>> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com >> >> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs >> team >> are watching. >> >> But >> >> a) I'm not subscribed to linux-xfs and >> >> b) the changelog fails to describe the userspace-visible effects of >>the bug, so I (and others) are unable to determine which kernel >>versions should be patched. >> >> Please update that changelog and resend? > > I will apply "xfs: correct calculation for agend and blockcount" patch to > xfs-linux Git tree and include it for the next v6.6 pull request to Linus. > > At the outset, It looks like I can pick "mm, pmem, xfs: Introduce > MF_MEM_PRE_REMOVE for unbind" > (i.e. > https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u) > patch for v6.7 as well. But that will require your Ack. Please let me know > your opinion. > > Also, I will pick "xfs: drop experimental warning for FSDAX" patch for v6.7. While I hate to drag it out even longer, it seems slightly optimistic to drop experimental at the same time as the "last" fix, in case it's not really the last fix. But I don't have super strong feelings about it, and I would be happy to finally see experimental go away. So if those who are more tuned into the details are comfortable with that 6.7 plan, I'll defer to them on the question. Thanks, -Eric
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 pick the following patch[1] as well, which fixes failures of >> xfs55[0-2] cases. >> >> [1] >> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com > > I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs > team > are watching. > > But > > a) I'm not subscribed to linux-xfs and > > b) the changelog fails to describe the userspace-visible effects of >the bug, so I (and others) are unable to determine which kernel >versions should be patched. > > Please update that changelog and resend? I will apply "xfs: correct calculation for agend and blockcount" patch to xfs-linux Git tree and include it for the next v6.6 pull request to Linus. At the outset, It looks like I can pick "mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind" (i.e. https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.f...@fujitsu.com/T/#u) patch for v6.7 as well. But that will require your Ack. Please let me know your opinion. Also, I will pick "xfs: drop experimental warning for FSDAX" patch for v6.7. -- Chandan
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2023/9/29 1:13, Darrick J. Wong 写道: 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] https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs team are watching. But a) I'm not subscribed to linux-xfs and b) the changelog fails to describe the userspace-visible effects of the bug, so I (and others) are unable to determine which kernel versions should be patched. Please update that changelog and resend? That's a purely xfs patch anyways. The correct maintainer is Chandan, not Andrew. /me notes that post-reorg, patch authors need to ask the release manager (Chandan) directly to merge their patches after they've gone through review. Pull requests of signed tags are encouraged strongly. Shiyang, could you please send Chandan pull requests with /all/ the relevant pmem patches incorporated? I think that's one PR for the "xfs: correct calculation for agend and blockcount" for 6.6; and a second PR with all the non-bugfix stuff (PRE_REMOVE and whatnot) for 6.7. OK. Though I don't know how to send the PR by email, I have sent a list of the patches and added description for each one. -- Thanks, Ruan. --D
Re: [PATCH] xfs: drop experimental warning for FSDAX
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] > > https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com > > I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs > team > are watching. > > But > > a) I'm not subscribed to linux-xfs and > > b) the changelog fails to describe the userspace-visible effects of >the bug, so I (and others) are unable to determine which kernel >versions should be patched. > > Please update that changelog and resend? That's a purely xfs patch anyways. The correct maintainer is Chandan, not Andrew. /me notes that post-reorg, patch authors need to ask the release manager (Chandan) directly to merge their patches after they've gone through review. Pull requests of signed tags are encouraged strongly. Shiyang, could you please send Chandan pull requests with /all/ the relevant pmem patches incorporated? I think that's one PR for the "xfs: correct calculation for agend and blockcount" for 6.6; and a second PR with all the non-bugfix stuff (PRE_REMOVE and whatnot) for 6.7. --D
Re: [PATCH] xfs: drop experimental warning for FSDAX
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] > https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs team are watching. But a) I'm not subscribed to linux-xfs and b) the changelog fails to describe the userspace-visible effects of the bug, so I (and others) are unable to determine which kernel versions should be patched. Please update that changelog and resend?
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2023/9/27 23:30, Andrew Morton 写道: On Wed, 27 Sep 2023 13:01:25 +0530 Chandan Babu R wrote: 在 2023/9/27 13:17, Shiyang Ruan 写道: 在 2023/9/27 11:38, Chandan Babu R 写道: On Tue, Sep 26, 2023 at 06:46:32 PM -0700, Darrick J. Wong wrote: 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 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.bad 2023-09-24 20:00:23.4 -0700 @@ -3,7 +3,6 @@ Format and mount Create the original files Inject memory failure (1 page) Inject poison... -Process is killed by signal: 7 Inject memory failure (2 pages) Inject poison... -Process is killed by signal: 7 +Memory failure didn't kill the process (yes, rmap is enabled) Yes, I see the same failures, too. I've just been ignoring them because I thought that all the memory failure code was still not complete Oh, I bet we were supposed to have merged this https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ FYI, this one is in Andrew's mm-unstable tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-unstable&id=ff048e3e2d167927634a45f4f424338411a1c4e6 I'll move this into mm-hotfixes so it gets merged into mainline during this -rc cycle. Thanks. I'll send a new version per Dan's comment. Should it be backported into earlier kernels, via a cc:stable? If so, are we able to identify a Fixes: target? I think this patch is a feature implementation, so it doesn't need to be packported. But please pick the following patch[1] as well, which fixes failures of xfs55[0-2] cases. [1] https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com -- Thanks, Ruan. to complete the pmem media failure handling code. Should we (by which I mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? I can add this patch into XFS tree for 6.7. But I will need Acks from Andrew Morton and Dan Williams. To clarify further, I will need Acked-By for the patch at https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ That would be nice.
Re: [PATCH] xfs: drop experimental warning for FSDAX
On Wed, 27 Sep 2023 13:01:25 +0530 Chandan Babu R wrote: > > > 在 2023/9/27 13:17, Shiyang Ruan 写道: > > > > 在 2023/9/27 11:38, Chandan Babu R 写道: > >> On Tue, Sep 26, 2023 at 06:46:32 PM -0700, Darrick J. Wong wrote: > >>> 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 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.bad 2023-09-24 > > 20:00:23.4 -0700 > > @@ -3,7 +3,6 @@ Format and mount > > Create the original files > > Inject memory failure (1 page) > > Inject poison... > > -Process is killed by signal: 7 > > Inject memory failure (2 pages) > > Inject poison... > > -Process is killed by signal: 7 > > +Memory failure didn't kill the process > > > > (yes, rmap is enabled) > > Yes, I see the same failures, too. I've just been ignoring them > because I thought that all the memory failure code was still not > complete > >>> > >>> Oh, I bet we were supposed to have merged this > >>> > >>> https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ > > FYI, this one is in Andrew's mm-unstable tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-unstable&id=ff048e3e2d167927634a45f4f424338411a1c4e6 I'll move this into mm-hotfixes so it gets merged into mainline during this -rc cycle. Should it be backported into earlier kernels, via a cc:stable? If so, are we able to identify a Fixes: target? > > >>> > >>> to complete the pmem media failure handling code. Should we (by which I > >>> mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? > >>> > >> > >> I can add this patch into XFS tree for 6.7. But I will need Acks > >> from Andrew > >> Morton and Dan Williams. > > To clarify further, I will need Acked-By for the patch at > https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ That would be nice.
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2023/9/27 13:17, Shiyang Ruan 写道: > > 在 2023/9/27 11:38, Chandan Babu R 写道: >> On Tue, Sep 26, 2023 at 06:46:32 PM -0700, Darrick J. Wong wrote: >>> 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 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.bad 2023-09-24 > 20:00:23.4 -0700 > @@ -3,7 +3,6 @@ Format and mount > Create the original files > Inject memory failure (1 page) > Inject poison... > -Process is killed by signal: 7 > Inject memory failure (2 pages) > Inject poison... > -Process is killed by signal: 7 > +Memory failure didn't kill the process > > (yes, rmap is enabled) Yes, I see the same failures, too. I've just been ignoring them because I thought that all the memory failure code was still not complete >>> >>> Oh, I bet we were supposed to have merged this >>> >>> https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ FYI, this one is in Andrew's mm-unstable tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-unstable&id=ff048e3e2d167927634a45f4f424338411a1c4e6 >>> >>> to complete the pmem media failure handling code. Should we (by which I >>> mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? >>> >> >> I can add this patch into XFS tree for 6.7. But I will need Acks >> from Andrew >> Morton and Dan Williams. To clarify further, I will need Acked-By for the patch at https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ -- Chandan
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2023/9/27 13:17, Shiyang Ruan 写道: 在 2023/9/27 11:38, Chandan Babu R 写道: On Tue, Sep 26, 2023 at 06:46:32 PM -0700, Darrick J. Wong wrote: 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 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.bad 2023-09-24 20:00:23.4 -0700 @@ -3,7 +3,6 @@ Format and mount Create the original files Inject memory failure (1 page) Inject poison... -Process is killed by signal: 7 Inject memory failure (2 pages) Inject poison... -Process is killed by signal: 7 +Memory failure didn't kill the process (yes, rmap is enabled) Yes, I see the same failures, too. I've just been ignoring them because I thought that all the memory failure code was still not complete Oh, I bet we were supposed to have merged this https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ FYI, this one is in Andrew's mm-unstable tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-unstable&id=ff048e3e2d167927634a45f4f424338411a1c4e6 -- Thanks, Ruan. to complete the pmem media failure handling code. Should we (by which I mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? I can add this patch into XFS tree for 6.7. But I will need Acks from Andrew Morton and Dan Williams. Thanks! And this patch[1] fixes these 3 cases (xfs/55[0-2]). Please add this one as well. [1]: https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com -- Ruan.
Re: [PATCH] xfs: drop experimental warning for FSDAX
在 2023/9/27 11:38, Chandan Babu R 写道: On Tue, Sep 26, 2023 at 06:46:32 PM -0700, Darrick J. Wong wrote: 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 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 -0700 @@ -3,7 +3,6 @@ Format and mount Create the original files Inject memory failure (1 page) Inject poison... -Process is killed by signal: 7 Inject memory failure (2 pages) Inject poison... -Process is killed by signal: 7 +Memory failure didn't kill the process (yes, rmap is enabled) Yes, I see the same failures, too. I've just been ignoring them because I thought that all the memory failure code was still not complete Oh, I bet we were supposed to have merged this https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ to complete the pmem media failure handling code. Should we (by which I mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? I can add this patch into XFS tree for 6.7. But I will need Acks from Andrew Morton and Dan Williams. Thanks! And this patch[1] fixes these 3 cases (xfs/55[0-2]). Please add this one as well. [1]: https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.f...@fujitsu.com -- Ruan.
Re: [PATCH] xfs: drop experimental warning for FSDAX
On Tue, Sep 26, 2023 at 06:46:32 PM -0700, Darrick J. Wong wrote: > 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 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.bad 2023-09-24 20:00:23.4 >> > -0700 >> > @@ -3,7 +3,6 @@ Format and mount >> > Create the original files >> > Inject memory failure (1 page) >> > Inject poison... >> > -Process is killed by signal: 7 >> > Inject memory failure (2 pages) >> > Inject poison... >> > -Process is killed by signal: 7 >> > +Memory failure didn't kill the process >> > >> > (yes, rmap is enabled) >> >> Yes, I see the same failures, too. I've just been ignoring them >> because I thought that all the memory failure code was still not >> complete > > Oh, I bet we were supposed to have merged this > > https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ > > to complete the pmem media failure handling code. Should we (by which I > mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? > I can add this patch into XFS tree for 6.7. But I will need Acks from Andrew Morton and Dan Williams. -- Chandan
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 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 > > -0700 > > @@ -3,7 +3,6 @@ Format and mount > > Create the original files > > Inject memory failure (1 page) > > Inject poison... > > -Process is killed by signal: 7 > > Inject memory failure (2 pages) > > Inject poison... > > -Process is killed by signal: 7 > > +Memory failure didn't kill the process > > > > (yes, rmap is enabled) > > Yes, I see the same failures, too. I've just been ignoring them > because I thought that all the memory failure code was still not > complete Oh, I bet we were supposed to have merged this https://lore.kernel.org/linux-xfs/20230828065744.1446462-1-ruansy.f...@fujitsu.com/ to complete the pmem media failure handling code. Should we (by which I mostly mean Shiyang) ask Chandan to merge these two patches for 6.7? --D > -Dave. > -- > Dave Chinner > da...@fromorbit.com
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 notice that xfs/55[0-2] still fail on my fakepmem machine: > > --- /tmp/fstests/tests/xfs/550.out2023-09-23 09:40:47.839521305 -0700 > +++ /var/tmp/fstests/xfs/550.out.bad 2023-09-24 20:00:23.4 -0700 > @@ -3,7 +3,6 @@ Format and mount > Create the original files > Inject memory failure (1 page) > Inject poison... > -Process is killed by signal: 7 > Inject memory failure (2 pages) > Inject poison... > -Process is killed by signal: 7 > +Memory failure didn't kill the process > > (yes, rmap is enabled) Yes, I see the same failures, too. I've just been ignoring them because I thought that all the memory failure code was still not complete -Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] xfs: drop experimental warning for FSDAX
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 -0700 @@ -3,7 +3,6 @@ Format and mount Create the original files Inject memory failure (1 page) Inject poison... -Process is killed by signal: 7 Inject memory failure (2 pages) Inject poison... -Process is killed by signal: 7 +Memory failure didn't kill the process (yes, rmap is enabled) Not sure what that's about? --D > > > -- > Thanks, > Ruan. > > > 在 2023/9/15 14:38, Shiyang Ruan 写道: > > FSDAX and reflink can work together now, let's drop this warning. > > > > Signed-off-by: Shiyang Ruan > > --- > > fs/xfs/xfs_super.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > > index 1f77014c6e1a..faee773fa026 100644 > > --- a/fs/xfs/xfs_super.c > > +++ b/fs/xfs/xfs_super.c > > @@ -371,7 +371,6 @@ xfs_setup_dax_always( > > return -EINVAL; > > } > > - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own > > risk"); > > return 0; > > disable_dax:
Re: [PATCH] xfs: drop experimental warning for FSDAX
Hi, Any comments? -- Thanks, Ruan. 在 2023/9/15 14:38, Shiyang Ruan 写道: FSDAX and reflink can work together now, let's drop this warning. Signed-off-by: Shiyang Ruan --- fs/xfs/xfs_super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 1f77014c6e1a..faee773fa026 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -371,7 +371,6 @@ xfs_setup_dax_always( return -EINVAL; } - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own risk"); return 0; disable_dax:
[PATCH] xfs: drop experimental warning for FSDAX
FSDAX and reflink can work together now, let's drop this warning. Signed-off-by: Shiyang Ruan --- fs/xfs/xfs_super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 1f77014c6e1a..faee773fa026 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -371,7 +371,6 @@ xfs_setup_dax_always( return -EINVAL; } - xfs_warn(mp, "DAX enabled. Warning: EXPERIMENTAL, use at your own risk"); return 0; disable_dax: -- 2.42.0
