From: Dave Chinner <david@fromorbit.com>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs/187: fix new sb_features2 ftype stop case running
Date: Wed, 31 Aug 2016 10:00:51 +1000 [thread overview]
Message-ID: <20160831000051.GV22388@dastard> (raw)
In-Reply-To: <1472542532-16497-1-git-send-email-zlang@redhat.com>
On Tue, Aug 30, 2016 at 03:35:32PM +0800, Zorro Lang wrote:
> This case is too old, at that time there's no "ftype" feature for
> XFS. Due to this case need to clear features2 bits when mkfs.xfs,
> so ftype bit stop case running for long time.
>
> We care 6 features2 bits in this case:
>
> "ATTR2, LAZYSBCOUNT, PROJID32BIT, CRC, FTYPE, FINOBT"
>
> ATTR2 and LAZYSBCOUNT bits will be tested in case. FINBOT will be
> disabled if CRC=0. So this patch only check and disable PROJID32BIT,
> CRC and FTYPE features when mkfs.xfs.
>
> Signed-off-by: Zorro Lang <zlang@redhat.com>
> ---
>
> Hi,
>
> I think we shouldn't skip this case if user doesn't specify suitable
> MKFS_OPTIONS and MOUNT_OPTIONS. Because this case need complex options,
> nearly no one will specify these all options for xfstests at same time.
>
> Thanks,
> Zorro
>
> tests/xfs/187 | 51 ++++++++++++++++++++++++++++-----------------------
> 1 file changed, 28 insertions(+), 23 deletions(-)
>
> diff --git a/tests/xfs/187 b/tests/xfs/187
> index 836b924..5e7c677 100755
> --- a/tests/xfs/187
> +++ b/tests/xfs/187
> @@ -31,7 +31,6 @@ 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
> @@ -58,24 +57,32 @@ _supported_os Linux
>
> _require_scratch
> _require_attrs
> -_require_attr_v1
> -_require_projid16bit
>
> rm -f $seqres.full
> -
> +_scratch_mkfs >/dev/null 2>&1
> # Reset the options so that we can control what is going on here
> -export MKFS_OPTIONS=""
> -export MOUNT_OPTIONS=""
> -
> -# lazysb, attr2 and other feature bits are held in features2 and will require
> -# morebitsbit on So test with lazysb and without it to see if the morebitsbit is
> -# okay etc. If the mkfs defaults change, these need to change as well.
> -export MKFS_NO_LAZY="-m crc=0 -l lazy-count=0 -i projid32bit=0"
> -export MKFS_LAZY="-m crc=0 -l lazy-count=1 -i projid32bit=0"
> +MKFS_OPTIONS=""
> +MOUNT_OPTIONS=""
> +ver2=`$XFS_DB_PROG -c version $SCRATCH_DEV | sed -n -e "s/,/ /g" \
> + -e "s/.*MOREBITS\(.*\)/\1/p"`
> +# clear features2 bits which we won't test
> +for b in $ver2; do
> + case $b in
> + CRC)
> + MKFS_OPTIONS="$MKFS_OPTIONS -m crc=0"
> + ;;
> + PROJID32BIT)
> + MKFS_OPTIONS="$MKFS_OPTIONS -i projid32bit=0"
> + ;;
> + FTYPE)
> + MKFS_OPTIONS="$MKFS_OPTIONS -n ftype=0"
> + ;;
> + esac
> +done
We're doing stuff like this in way too many places to keep old tests
working with new xfsprogs as the defaults change and new options are
added. This is not maintainable in the long run.
I think we need to start marking test as requiring "old" filesystem
formats, and we configure the mkfs options required to create such a
filesystem in one place.
i.e. add a rule:
_require_old_xfs_format()
{
# calculate necessary additional options to ensure
# 16 bit project id, no CRCs, and no ftype.
BASIC_MKFS_OPTIONS=.....
# add "old" option to default mkfs option set
export MKFS_OPTION=S"$MKFS_OPTIONS $BASIC_MKFS_OPTIONS"
}
And now any specific test that relies on a format not having CRCs,
ftype, etc, can simply _require_old_xfs_format(), and so we can
get rid of all the per-test magic we have to futz mkfs options into
the "old" format the test requires.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2016-08-31 0:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-30 7:35 [PATCH] xfs/187: fix new sb_features2 ftype stop case running Zorro Lang
2016-08-31 0:00 ` Dave Chinner [this message]
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=20160831000051.GV22388@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=xfs@oss.sgi.com \
--cc=zlang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).