From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
fstests@vger.kernel.org
Cc: kernel@pankajraghav.com, gost.dev@samsung.com, mcgrof@kernel.org,
djwong@kernel.org, zlang@redhat.com,
Pankaj Raghav <p.raghav@samsung.com>
Subject: Re: [PATCH v2 1/3] xfs/161: adapt the test case for 64k FS blocksize
Date: Tue, 14 May 2024 17:49:12 +0530 [thread overview]
Message-ID: <87ttj0bn7j.fsf@gmail.com> (raw)
In-Reply-To: <20240513131254.92412-2-kernel@pankajraghav.com>
"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com> writes:
> From: Pankaj Raghav <p.raghav@samsung.com>
>
> This test fails when xfs is formatted with 64k filesystem block size*.
> It fails because the soft quota is not exceeded with the hardcoded 64k
> pwrite, thereby, the grace time is not set. Even though soft quota is
> set to 12k for uid1, it is rounded up to the nearest blocksize.
>
> *** Report for user quotas on device /dev/sdb3
> Block grace time: 7days; Inode grace time: 7days
> Block limits File limits
> User used soft hard grace used soft hard grace
> ----------------------------------------------------------------------
> 0 -- 0 0 0 0 3 0 0 0
> 1 -- 64 64 1024 0 1 0 0 0
> 2 -- 64 0 0 0 1 0 0 0
>
> Adapt the pwrite to do twice the FS block size and set the soft limit
> to be 1 FS block and hard limit to be 100 FS blocks. This also gets rid
> of harcoded quota limit values.
>
> * This happens even on a 64k pagesize system and it is not related to
> LBS effort.
>
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Looks good to me. Small nit below.
(I can verify on Power once I am back)
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> tests/xfs/161 | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/tests/xfs/161 b/tests/xfs/161
> index 486fa6ca..5bda7019 100755
> --- a/tests/xfs/161
> +++ b/tests/xfs/161
> @@ -38,15 +38,23 @@ _qmount_option "usrquota"
> _scratch_xfs_db -c 'version' -c 'sb 0' -c 'p' >> $seqres.full
> _scratch_mount >> $seqres.full
>
> +
> +blksz=$(_get_file_block_size "$SCRATCH_MNT")
> +# Write more than one block to exceed the soft block quota limit via
> +# xfs_quota.
> +filesz=$(( 2 * $blksz))
> +lim_bsoft=$blksz
> +lim_bhard=$(( 100 * blksz ))
> +
> # Force the block counters for uid 1 and 2 above zero
> -_pwrite_byte 0x61 0 64k $SCRATCH_MNT/a >> $seqres.full
> -_pwrite_byte 0x61 0 64k $SCRATCH_MNT/b >> $seqres.full
> +_pwrite_byte 0x61 0 $filesz $SCRATCH_MNT/a >> $seqres.full
> +_pwrite_byte 0x61 0 $filesz $SCRATCH_MNT/b >> $seqres.full
> sync
> chown 1 $SCRATCH_MNT/a
> chown 2 $SCRATCH_MNT/b
>
> # Set quota limits on uid 1 before upgrading
> -$XFS_QUOTA_PROG -x -c 'limit -u bsoft=12k bhard=1m 1' $SCRATCH_MNT
> +$XFS_QUOTA_PROG -x -c 'limit -u bsoft='"$lim_bsoft"' bhard='"$lim_bhard"' 1' $SCRATCH_MNT
Small nit: I am not sure if we really need so many quotes for '"$lim_bsoft"' and
"'$lim_bhard"'.
>
> # Make sure the grace period is at /some/ point in the future. We have to
> # use bc because not all bashes can handle integer comparisons with 64-bit
> @@ -71,7 +79,7 @@ _scratch_mount
>
> # Set a very generous grace period and quota limits on uid 2 after upgrading
> $XFS_QUOTA_PROG -x -c 'timer -u -b -d 2147483647' $SCRATCH_MNT
> -$XFS_QUOTA_PROG -x -c 'limit -u bsoft=10000 bhard=150000 2' $SCRATCH_MNT
> +$XFS_QUOTA_PROG -x -c 'limit -u bsoft='"$lim_bsoft"' bhard='"$lim_bhard"' 2' $SCRATCH_MNT
>
> # Query the grace periods to see if they got set properly after the upgrade.
> repquota -upn $SCRATCH_MNT > $tmp.repquota
> --
> 2.34.1
next prev parent reply other threads:[~2024-05-14 12:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 13:12 [PATCH v2 0/3] more lbs test fixes Pankaj Raghav (Samsung)
2024-05-13 13:12 ` [PATCH v2 1/3] xfs/161: adapt the test case for 64k FS blocksize Pankaj Raghav (Samsung)
2024-05-14 12:19 ` Ritesh Harjani [this message]
2024-05-13 13:12 ` [PATCH v2 2/3] generic/436: round up bufsz to nearest filesystem blksz Pankaj Raghav (Samsung)
2024-05-17 15:54 ` Darrick J. Wong
2024-05-22 20:48 ` Ritesh Harjani
2024-05-13 13:12 ` [PATCH v2 3/3] xfs/008: use block size instead of the pagesize Pankaj Raghav (Samsung)
2024-05-23 4:25 ` Ritesh Harjani
2024-05-27 11:42 ` Pankaj Raghav (Samsung)
2024-05-25 5:48 ` [PATCH v2 0/3] more lbs test fixes Zorro Lang
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=87ttj0bn7j.fsf@gmail.com \
--to=ritesh.list@gmail.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=gost.dev@samsung.com \
--cc=kernel@pankajraghav.com \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.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 read-only IMAP folder(s) and NNTP newsgroup(s).