All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: fstests <fstests@vger.kernel.org>, linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: test that default grace periods init on first mount
Date: Thu, 20 Feb 2020 12:50:50 +0800	[thread overview]
Message-ID: <20200220045050.GF14282@dhcp-12-102.nay.redhat.com> (raw)
In-Reply-To: <7c6b4646-d7c5-cc03-9c90-c17daa22071d@redhat.com>

On Wed, Feb 19, 2020 at 09:26:29PM -0600, Eric Sandeen wrote:
> There's currently a bug in how default grace periods get set up
> before the very first quotacheck runs; we try to read the quota
> inodes before they are populated, and so the grace periods remain
> empty.  The /next/ mount fills them in.  This is a regression test
> for that bug.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> diff --git a/tests/xfs/995 b/tests/xfs/995
> new file mode 100755
> index 00000000..477855b8
> --- /dev/null
> +++ b/tests/xfs/995
> @@ -0,0 +1,50 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020 Red Hat, Inc.  All Rights Reserved.
> +#
> +# FS QA Test 995
> +#
> +# Regression test xfs flaw which did not report proper quota default
> +# grace periods until the 2nd mount of a new filesystem with quota.
> +#
> +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
> +. ./common/quota
> +
> +# remove previous $seqres.full before test
> +rm -f $seqres.full
> +
> +# real QA test starts here
> +_supported_fs generic
> +_supported_os Linux
> +_require_scratch
> +_require_quota

If this's xfs specified case, I think "_require_xfs_quota" might be better then
_require_quota, at least it checks "XFS_QUOTA_PROG" and some xfs specified
things.

BTW, do you think "_require_xfs_quota_foreign" can help this case to be a
generic case?

> +
> +_scratch_mkfs >$seqres.full 2>&1
> +_qmount_option "usrquota"
> +_qmount
> +
> +xfs_quota -x -c "state -u" $SCRATCH_MNT | grep "grace time"

I think $XFS_QUOTA_PROG would be better than using xfs_quota directly.

> +_scratch_unmount
> +_qmount
> +xfs_quota -x -c "state -u" $SCRATCH_MNT | grep "grace time"
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/xfs/995.out b/tests/xfs/995.out
> new file mode 100644
> index 00000000..d10017d1
> --- /dev/null
> +++ b/tests/xfs/995.out
> @@ -0,0 +1,7 @@
> +QA output created by 995
> +Blocks grace time: [7 days]
> +Inodes grace time: [7 days]
> +Realtime Blocks grace time: [7 days]
> +Blocks grace time: [7 days]
> +Inodes grace time: [7 days]
> +Realtime Blocks grace time: [7 days]

Hmm... but if the bug is on the default grace time itself, and different
filesystems have different default timers, then I think a xfs specified case
would be better. I don't have a better idea to make it a generic case.

The case from me:
  [PATCH 1/2] generic: per-type quota timers set/get test
Although it trys to test default quota time too, but I think it can't verify
this bug properly, especially if the default time isn't correctly at beginning.
Feel free to correct me, if you have a better idea:)

Thanks,
Zorro

> diff --git a/tests/xfs/group b/tests/xfs/group
> index 0cbd0647..235a2715 100644
> --- a/tests/xfs/group
> +++ b/tests/xfs/group
> @@ -511,3 +511,4 @@
>  511 auto quick quota
>  512 auto quick acl attr
>  513 auto mount
> +995 auto quota quick
> 


  reply	other threads:[~2020-02-20  4:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20  3:26 [PATCH] xfs: test that default grace periods init on first mount Eric Sandeen
2020-02-20  4:50 ` Zorro Lang [this message]
2020-03-02 22:48 ` Eric Sandeen

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=20200220045050.GF14282@dhcp-12-102.nay.redhat.com \
    --to=zlang@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@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 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.