From: Xiao Yang <yangx.jy@cn.fujitsu.com>
To: Ira Weiny <ira.weiny@intel.com>
Cc: <fstests@vger.kernel.org>, <darrick.wong@oracle.com>
Subject: Re: [PATCH v6 7/7] generic: Verify the inheritance behavior of FS_XFLAG_DAX flag in various combinations
Date: Wed, 15 Jul 2020 17:44:53 +0800 [thread overview]
Message-ID: <5F0ED015.5090707@cn.fujitsu.com> (raw)
In-Reply-To: <5F0E96A8.2010705@cn.fujitsu.com>
On 2020/7/15 13:39, Xiao Yang wrote:
> On 2020/7/15 10:48, Ira Weiny wrote:
>> On Tue, Jul 14, 2020 at 05:40:09PM +0800, Xiao Yang wrote:
>>> Signed-off-by: Xiao Yang<yangx.jy@cn.fujitsu.com>
>>> ---
>>> tests/generic/605 | 199
>>> ++++++++++++++++++++++++++++++++++++++++++
>>> tests/generic/605.out | 2 +
>>> tests/generic/group | 1 +
>>> 3 files changed, 202 insertions(+)
>>> create mode 100644 tests/generic/605
>>> create mode 100644 tests/generic/605.out
>>>
>>> diff --git a/tests/generic/605 b/tests/generic/605
>>> new file mode 100644
>>> index 00000000..6924223a
>>> --- /dev/null
>>> +++ b/tests/generic/605
>>> @@ -0,0 +1,199 @@
>>> +#! /bin/bash
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +# Copyright (c) 2020 Fujitsu. All Rights Reserved.
>>> +#
>>> +# FS QA Test 605
>>> +#
>>> +# Verify the inheritance behavior of FS_XFLAG_DAX flag in various
>>> combinations.
>>> +# 1) New files and directories automatically inherit FS_XFLAG_DAX
>>> from their parent directory.
>>> +# 2) cp operation make files and directories inherit the
>>> FS_XFLAG_DAX from new parent directory.
>>> +# 3) mv operation make files and directories preserve the
>>> FS_XFLAG_DAX from old parent directory.
>>> +# In addition, setting/clearing FS_XFLAG_DAX flag is not impacted
>>> by dax mount options.
>>> +
>>> +seq=`basename $0`
>>> +seqres=$RESULT_DIR/$seq
>>> +echo "QA output created by $seq"
>>> +
>>> +here=`pwd`
>>> +tmp=/tmp/$$
>>> +status=1 # failure is the default!
>>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>>> +
>>> +_cleanup()
>>> +{
>>> + cd /
>>> + rm -f $tmp.*
>>> +}
>>> +
>>> +# get standard environment, filters and checks
>>> +. ./common/rc
>>> +. ./common/filter
>>> +
>>> +# remove previous $seqres.full before test
>>> +rm -f $seqres.full
>>> +
>>> +_supported_fs generic
>>> +_supported_os Linux
>>> +_require_scratch
>>> +_require_dax_iflag
>>> +_require_xfs_io_command "lsattr" "-v"
>>> +
>>> +check_xflag()
>>> +{
>>> + local target=$1
>>> + local exp_xflag=$2
>>> +
>>> + if [ $exp_xflag -eq 0 ]; then
>>> + _test_inode_flag dax $target&& echo "$target has
>>> unexpected FS_XFLAG_DAX flag"
>>> + else
>>> + _test_inode_flag dax $target || echo "$target doen't have
>>> expected FS_XFLAG_DAX flag"
>>> + fi
>>> +}
>>> +
>>> +test_xflag_inheritance1()
>>> +{
>>> + mkdir -p a
>>> + $XFS_IO_PROG -c "chattr +x" a
>>> + mkdir -p a/b/c
>>> + touch a/b/c/d
>>> +
>>> + check_xflag a 1
>>> + check_xflag a/b 1
>>> + check_xflag a/b/c 1
>>> + check_xflag a/b/c/d 1
>>> +
>>> + rm -rf a
>>> +}
>>> +
>>> +test_xflag_inheritance2()
>>> +{
>>> + mkdir -p a/b
>>> + $XFS_IO_PROG -c "chattr +x" a
>>> + mkdir -p a/b/c a/d
>>> + touch a/b/c/e a/d/f
>>> +
>>> + check_xflag a 1
>>> + check_xflag a/b 0
>>> + check_xflag a/b/c 0
>>> + check_xflag a/b/c/e 0
>>> + check_xflag a/d 1
>>> + check_xflag a/d/f 1
>>> +
>>> + rm -rf a
>>> +}
>>> +
>>> +test_xflag_inheritance3()
>>> +{
>>> + mkdir -p a/b
>>> + $XFS_IO_PROG -c "chattr +x" a/b
>>> + mkdir -p a/b/c a/d
>>> + touch a/b/c/e a/d/f
>>> +
>>> + check_xflag a 0
>>> + check_xflag a/b 1
>>> + check_xflag a/b/c 1
>>> + check_xflag a/b/c/e 1
>>> + check_xflag a/d 0
>>> + check_xflag a/d/f 0
>>> +
>>> + rm -rf a
>>> +}
>> It really seems like 2 and 3 test the same thing?
> Hi Ira,
>
> 2 constructs the following steps:
> 1) a is the parent directory of b
> 2) a doesn't have xflag and b has xflag
> 3) touch many directories/files in a and b
>
> 3 constructs the following steps:
> 1) a is the parent directory of b and b is the parent directory of c
> 2) a and c have xflag, and b doesn't have xflag
> 3) touch many directories/files in b and c
Hi Ira,
Sorry for misreading your comment, above is the difference between 3 and 4.
The correct one is:
2 constructs the following steps:
1) a is the parent directory of b
2) a has xflag and b doesn't have xflag
3) touch many directories/files in a and b
3 constructs the following steps:
1) a is the parent directory of b
2) a doesn't have xflag and b has xflag
3) touch many directories/files in a and b
Do you think they are same? I can remove one if you think so.
Best Regards,
Xiao Yang
>
> Do you think they are same? I can remove one if you think so.
>
>>> +
>>> +test_xflag_inheritance4()
>>> +{
>>> + mkdir -p a
>>> + $XFS_IO_PROG -c "chattr +x" a
>>> + mkdir -p a/b/c
>>> + $XFS_IO_PROG -c "chattr -x" a/b
>>> + mkdir -p a/b/c/d a/b/e
>>> + touch a/b/c/d/f a/b/e/g
>>> +
>>> + check_xflag a 1
>>> + check_xflag a/b 0
>>> + check_xflag a/b/c 1
>>> + check_xflag a/b/c/d 1
>>> + check_xflag a/b/c/d/f 1
>>> + check_xflag a/b/e 0
>>> + check_xflag a/b/e/g 0
>>> +
>>> + rm -rf a
>>> +}
>>> +
>>> +test_xflag_inheritance5()
>>> +{
>>> + mkdir -p a b
>>> + $XFS_IO_PROG -c "chattr +x" a
>>> + mkdir -p a/c a/d b/e b/f
>>> + touch a/g b/h
>>> +
>>> + cp -r a/c b/
>>> + cp -r b/e a/
>>> + cp -r a/g b/
>>> + mv a/d b/
>>> + mv b/f a/
>>> + mv b/h a/
>>> +
>>> + check_xflag b/c 0
>>> + check_xflag b/d 1
>>> + check_xflag a/e 1
>>> + check_xflag a/f 0
>>> + check_xflag b/g 0
>>> + check_xflag a/h 0
>>> +
>>> + rm -rf a b
>>> +}
>>> +
>>> +do_xflag_tests()
>>> +{
>>> + local option=$1
>>> +
>>> + _scratch_mount "$option"
>>> + cd $SCRATCH_MNT
>>> +
>>> + for i in $(seq 1 5); do
>>> + test_xflag_inheritance${i}
>>> + done
>>> +
>>> + cd -> /dev/null
>>> + _scratch_unmount
>>> +}
>>> +
>>> +check_dax_mountopt()
>>> +{
>>> + local option=$1
>>> + local ret=0
>>> +
>>> + _try_scratch_mount "-o $option">> $seqres.full 2>&1 || return 1
>>> +
>>> + # Match option name exactly
>>> + _fs_options $SCRATCH_DEV | egrep -q "$option(,|$)" || ret=1
>>> +
>>> + _scratch_unmount
>>> +
>>> + return $ret
>>> +}
>> Should this be a common function?
>
> I am not sure if it should be a common function, because it may not be
> used by other tests in future.
> I also consider to merge the function into
> _require_scratch_dax_mountopt().
>
>>> +
>>> +do_tests()
>>> +{
>>> + # Mount without dax option
>>> + do_xflag_tests
>>> +
>>> + # Mount with old dax option if fs only supports it.
>>> + check_dax_mountopt "dax"&& do_xflag_tests "-o dax"
>> I don't understand the order here. If we are on an older kernel and
>> the FS
>> only supports '-o dax' the do_xflag_tests will fail won't it?
>
> With both old dax and new dax, the inheritance behavior of
> FS_XFLAG_DAX works well.
>
>> So shouldn't we do this first and bail/'not run' this test if that is
>> the case?
>>
>> I really don't think there is any point in testing the old XFS
>> behavior because
>> the FS_XFLAG_DAX had no effect. So even if it is broken it does not
>> matter.
>> Or perhaps I am missing something here?
>
> This test is designed to verify the inheritance behavior of
> FS_XFLAG_DAX(not related to S_DAX)
> so I think it is fine for both old dax and new dax to run the test.
>
> Best Regards,
> Xiao Yang
>> Ira
>>
>>> +
>>> + # Mount with new dax options if fs supports them.
>>> + if check_dax_mountopt "dax=always"; then
>>> + for dax_option in "dax=always" "dax=inode" "dax=never"; do
>>> + do_xflag_tests "-o $dax_option"
>>> + done
>>> + fi
>>> +}
>>> +
>>> +_scratch_mkfs>> $seqres.full 2>&1
>>> +
>>> +do_tests
>>> +
>>> +# success, all done
>>> +echo "Silence is golden"
>>> +status=0
>>> +exit
>>> diff --git a/tests/generic/605.out b/tests/generic/605.out
>>> new file mode 100644
>>> index 00000000..1ae20049
>>> --- /dev/null
>>> +++ b/tests/generic/605.out
>>> @@ -0,0 +1,2 @@
>>> +QA output created by 605
>>> +Silence is golden
>>> diff --git a/tests/generic/group b/tests/generic/group
>>> index 676e0d2e..a8451862 100644
>>> --- a/tests/generic/group
>>> +++ b/tests/generic/group
>>> @@ -607,3 +607,4 @@
>>> 602 auto quick encrypt
>>> 603 auto attr quick dax
>>> 604 auto attr quick dax
>>> +605 auto attr quick dax
>>> --
>>> 2.21.0
>>>
>>>
>>>
>>
>> .
>>
>
>
>
> .
>
next prev parent reply other threads:[~2020-07-15 9:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 9:40 [PATCH v6 0/7] Make fstests support new behavior of DAX Xiao Yang
2020-07-14 9:40 ` [PATCH v6 1/7] common/rc: Introduce new helpers for DAX mount options and FS_XFLAG_DAX Xiao Yang
2020-07-15 1:59 ` Ira Weiny
2020-07-15 3:19 ` Xiao Yang
2020-07-15 4:15 ` Ira Weiny
2020-07-15 5:55 ` Xiao Yang
2020-07-15 15:56 ` Darrick J. Wong
2020-07-15 18:00 ` Ira Weiny
2020-07-14 9:40 ` [PATCH v6 2/7] fstests: Use _require_scratch_dax_mountopt() and _require_dax_iflag() Xiao Yang
2020-07-15 16:08 ` Darrick J. Wong
2020-07-14 9:40 ` [PATCH v6 3/7] generic/223: Don't clear all mkfs options for _scratch_mkfs_geom() roughly Xiao Yang
2020-07-15 2:31 ` Ira Weiny
2020-07-15 3:12 ` Xiao Yang
2020-07-15 16:07 ` Darrick J. Wong
2020-07-16 1:36 ` Xiao Yang
2020-07-14 9:40 ` [PATCH v6 4/7] generic/413, xfs/260: Improve format operation for PMD fault testing Xiao Yang
2020-07-15 16:09 ` Darrick J. Wong
2020-07-14 9:40 ` [PATCH v6 5/7] xfs/260: Move and update xfs/260 Xiao Yang
2020-07-15 16:10 ` Darrick J. Wong
2020-07-14 9:40 ` [PATCH v6 6/7] generic: Verify if statx() can qurey S_DAX flag on regular file correctly Xiao Yang
2020-07-14 9:40 ` [PATCH v6 7/7] generic: Verify the inheritance behavior of FS_XFLAG_DAX flag in various combinations Xiao Yang
2020-07-15 2:48 ` Ira Weiny
2020-07-15 5:39 ` Xiao Yang
2020-07-15 8:10 ` Xiao Yang
2020-07-15 16:43 ` Xiao Yang
2020-07-15 9:44 ` Xiao Yang [this message]
2020-07-15 16:19 ` Darrick J. Wong
2020-07-15 16:33 ` Xiao Yang
2020-07-15 18:18 ` Ira Weiny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5F0ED015.5090707@cn.fujitsu.com \
--to=yangx.jy@cn.fujitsu.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=ira.weiny@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.