public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Zorro Lang <zlang@kernel.org>,
	fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] generic: soft quota limits testing within grace time
Date: Fri, 6 May 2022 10:12:50 -0700	[thread overview]
Message-ID: <20220506171250.GT27195@magnolia> (raw)
In-Reply-To: <20220506165441.3elwulgaipfdpruu@zlang-mailbox>

On Sat, May 07, 2022 at 12:54:41AM +0800, Zorro Lang wrote:
> On Fri, May 06, 2022 at 09:19:29AM -0700, Darrick J. Wong wrote:
> > On Fri, May 06, 2022 at 02:25:55AM +0800, Zorro Lang wrote:
> > > After soft limits are exceeded, within the grace time, fs quota should
> > > allow more space allocation before exceeding hard limits, even if
> > > allocating many small files.
> > > 
> > > This case can cover bc37e4fb5cac (xfs: revert "xfs: actually bump
> > > warning counts when we send warnings"). And will help to expose later
> > > behavior changes on this side.
> > > 
> > > Signed-off-by: Zorro Lang <zlang@redhat.com>
> > > ---
> > >  tests/generic/690     | 125 ++++++++++++++++++++++++++++++++++++++++++
> > >  tests/generic/690.out |   2 +
> > >  2 files changed, 127 insertions(+)
> > >  create mode 100755 tests/generic/690
> > >  create mode 100644 tests/generic/690.out
> > > 
> > > diff --git a/tests/generic/690 b/tests/generic/690
> > > new file mode 100755
> > > index 00000000..b1d055dc
> > > --- /dev/null
> > > +++ b/tests/generic/690
> > > @@ -0,0 +1,125 @@
> > > +#! /bin/bash
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +# Copyright (c) 2022 Red Hat Inc.  All Rights Reserved.
> > > +#
> > > +# FS QA Test 690
> > > +#
> > > +# Make sure filesystem quota works well, after soft limits are exceeded. The
> > > +# fs quota should allow more space allocation before exceeding hard limits
> > > +# and with in grace time.
> > 
> > 'within'
> 
> Thanks, a typo :-D
> 
> > 
> > > +#
> > > +# But different with other similar testing, this case trys to write many small
> > > +# files, to cover bc37e4fb5cac (xfs: revert "xfs: actually bump warning counts
> > > +# when we send warnings"). If there's a behavior change in one day, this case
> > > +# might help to detect that too.
> > > +#
> > > +. ./common/preamble
> > > +_begin_fstest auto quota
> > > +
> > > +# Override the default cleanup function.
> > > +_cleanup()
> > > +{
> > > +	restore_project
> > > +	cd /
> > > +	rm -r -f $tmp.*
> > > +}
> > > +
> > > +# Import common functions.
> > > +. ./common/quota
> > > +
> > > +# real QA test starts here
> > > +_supported_fs generic
> > > +_require_scratch
> > > +_require_quota
> > > +_require_user
> > > +_require_group
> > > +
> > > +create_project()
> > > +{
> > > +	rm -rf $SCRATCH_MNT/t
> > > +	mkdir $SCRATCH_MNT/t
> > > +	$XFS_IO_PROG -r -c "chproj 100" -c "chattr +P" $SCRATCH_MNT/t
> > > +	chmod ugo+rwx $SCRATCH_MNT/t/
> > > +
> > > +	rm -f $tmp.projects $tmp.projid
> > > +	if [ -f /etc/projects ];then
> > > +		cat /etc/projects > $tmp.projects
> > > +	fi
> > > +	if [ -f /etc/projid ];then
> > > +		cat /etc/projid > $tmp.projid
> > > +	fi
> > > +
> > > +	cat >/etc/projects <<EOF
> > > +100:$SCRATCH_MNT/t
> > > +EOF
> > > +	cat >/etc/projid <<EOF
> > > +$qa_user:100
> > > +EOF
> > > +	PROJECT_CHANGED=1
> > > +}
> > > +
> > > +restore_project()
> > > +{
> > > +	if [ "$PROJECT_CHANGED" = "1" ];then
> > > +		rm -f /etc/projects /etc/projid
> > > +		if [ -f $tmp.projects ];then
> > > +			cat $tmp.projects > /etc/projects
> > > +		fi
> > > +		if [ -f $tmp.projid ];then
> > > +			cat $tmp.projid > /etc/projid
> > > +		fi
> > > +	fi
> > > +}
> > 
> > Please just hoist these out of generic/603.
> 
> Do you mean make create_project() and restore_project() to be common functions
> in common/quota ?

Yep.

> > 
> > > +
> > > +# Make sure the kernel supports project quota
> > > +_scratch_mkfs >$seqres.full 2>&1
> > > +_scratch_enable_pquota
> > > +_qmount_option "prjquota"
> > > +_qmount
> > > +_require_prjquota $SCRATCH_DEV
> > > +
> > > +exercise()
> > > +{
> > > +	local type=$1
> > > +	local file=$SCRATCH_MNT/testfile
> > > +
> > > +	echo "= Test type=$type quota =" >>$seqres.full
> > > +	_scratch_unmount
> > > +	_scratch_mkfs >>$seqres.full 2>&1
> > > +	if [ "$1" = "P" ];then
> > > +		_scratch_enable_pquota
> > > +	fi
> > > +	_qmount
> > > +	if [ "$1" = "P" ];then
> > > +		create_project
> > > +		file=$SCRATCH_MNT/t/testfile
> > > +	fi
> > > +
> > > +	setquota -${type} $qa_user 1M 500M 0 0 $SCRATCH_MNT
> > > +	setquota -${type} -t 86400 86400 $SCRATCH_MNT
> > > +	repquota -v -${type} $SCRATCH_MNT | grep -v "^root" >>$seqres.full 2>&1
> > 
> > So this sets a soft limit of 1M, a hard limit of 500M, and a grace
> > period of one day?  And then we try to write 101M to a file?
> 
> Maybe 102M, due to the first file is 2M, to exceed soft limit(1M), then later
> 100*1M files. Anyway, the 102M isn't necessary, just try to create a scattering
> of hundred files. Hope 100 is enough :)

<nod>

--D

> > 
> > I think this looks good other than the remarks I had above.
> > 
> > --D
> > 
> > > +	# Exceed the soft quota limit a bit at first
> > > +	su $qa_user -c "$XFS_IO_PROG -f -t -c 'pwrite 0 2m' -c fsync ${file}.0" >>$seqres.full 2>&1
> > > +	# Write more data more times under soft quota limit exhausted condition,
> > > +	# but not reach hard limit. To make sure the it won't trigger EDQUOT.
> > > +	for ((i=1; i<=100; i++));do
> > > +		su "$qa_user" -c "$XFS_IO_PROG -f -c 'pwrite 0 1m' -c fsync ${file}.$i" >>$seqres.full 2>&1
> > > +		if [ $? -ne 0 ];then
> > > +			log "Unexpected error (type=$type)!"
> > > +			break
> > > +		fi
> > > +	done
> > > +	repquota -v -${type} $SCRATCH_MNT | grep -v "^root" >>$seqres.full 2>&1
> > > +}
> > > +
> > > +_qmount_option "usrquota"
> > > +exercise u
> > > +_qmount_option "grpquota"
> > > +exercise g
> > > +_qmount_option "prjquota"
> > > +exercise P
> > > +
> > > +echo "Silence is golden"
> > > +# success, all done
> > > +status=0
> > > +exit
> > > diff --git a/tests/generic/690.out b/tests/generic/690.out
> > > new file mode 100644
> > > index 00000000..6f3723e3
> > > --- /dev/null
> > > +++ b/tests/generic/690.out
> > > @@ -0,0 +1,2 @@
> > > +QA output created by 690
> > > +Silence is golden
> > > -- 
> > > 2.31.1
> > > 
> > 
> 

      reply	other threads:[~2022-05-06 17:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 18:25 [PATCH] generic: soft quota limits testing within grace time Zorro Lang
2022-05-05 18:43 ` Darrick J. Wong
2022-05-06  4:59   ` Zorro Lang
2022-05-06 16:19     ` Darrick J. Wong
2022-05-06 16:19 ` Darrick J. Wong
2022-05-06 16:54   ` Zorro Lang
2022-05-06 17:12     ` Darrick J. Wong [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=20220506171250.GT27195@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@kernel.org \
    /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