From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
"Darrick J. Wong" <djwong@kernel.org>
Cc: fstests@vger.kernel.org, gost.dev@samsung.com, mcgrof@kernel.org,
zlang@redhat.com, Pankaj Raghav <p.raghav@samsung.com>
Subject: Re: [PATCH 1/3] xfs/161: adapt the test case for 64k FS blocksize
Date: Thu, 09 May 2024 23:03:08 +0530 [thread overview]
Message-ID: <87ttj6gaaz.fsf@gmail.com> (raw)
In-Reply-To: <20240508105852.nfjtlp53v24xb3tw@quentin>
"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com> writes:
> On Tue, May 07, 2024 at 03:23:23PM -0700, Darrick J. Wong wrote:
>> On Mon, May 06, 2024 at 05:01:17PM +0200, Pankaj Raghav (Samsung) wrote:
>> > 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 more than 64k write when the FS blocksize is 64k.
>> >
>> > Cap the blksz to be at least 64k to retain the same behaviour as before
>> > for smaller filesystem blocksizes.
>> >
>> > * 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>
>> > ---
>> > tests/xfs/161 | 10 ++++++++--
>> > 1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/tests/xfs/161 b/tests/xfs/161
>> > index 486fa6ca..94290f18 100755
>> > --- a/tests/xfs/161
>> > +++ b/tests/xfs/161
>> > @@ -38,9 +38,15 @@ _qmount_option "usrquota"
>> > _scratch_xfs_db -c 'version' -c 'sb 0' -c 'p' >> $seqres.full
>> > _scratch_mount >> $seqres.full
>> >
>> > +min_blksz=65536
>> > +file_blksz=$(_get_file_block_size "$SCRATCH_MNT")
>> > +# Write more than one block to exceed the soft block quota limit.
>> > +blksz=$(( 2 * $file_blksz))
>> > +
>> > +blksz=$(( blksz > min_blksz ? blksz : min_blksz ))
>>
>> If we don't set $min_blksize and always write (2 * $file_blksz) does the
>> test still work?
>
> I think something like this is more clean where we don't have anymore
> hardcoded variables:
>
Yes, why not.
> Author: Pankaj Raghav <p.raghav@samsung.com>
> Date: Thu Jan 18 18:40:39 2024 +0100
>
> xfs/161: adapt the test case for 64k FS blocksize
>
> 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.
>
> * 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>
>
> diff --git a/tests/xfs/161 b/tests/xfs/161
> index 486fa6ca..074acddc 100755
> --- a/tests/xfs/161
> +++ b/tests/xfs/161
> @@ -38,15 +38,21 @@ _qmount_option "usrquota"
> _scratch_xfs_db -c 'version' -c 'sb 0' -c 'p' >> $seqres.full
> _scratch_mount >> $seqres.full
>
> +
> +pgsize=`$here/src/feature -s`
> +file_blksz=$(_get_file_block_size "$SCRATCH_MNT")
small bit: maybe just $blksz is fine.
> +# Write more than one block to exceed the soft block quota limit.
> +blksz=$(( 2 * $file_blksz))
small nit: Instead of blksz here maybe writesz or filesz then?
Then let's make:
lim_bsoft=$blksz, lim_bhard=$(( 10 * blksz )) and writesz=$(( 2 * 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 $blksz $SCRATCH_MNT/a >> $seqres.full
> +_pwrite_byte 0x61 0 $blksz $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='"$file_blksz"' bhard=1m 1' $SCRATCH_MNT
Then we can use $lim_bsoft and $lim_bhard here.
>
> # 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 +77,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='"$file_blksz"' bhard=150000 2' $SCRATCH_MNT
>
> # Query the grace periods to see if they got set properly after the upgrade.
> repquota -upn $SCRATCH_MNT > $tmp.repquota
>
-ritesh
next prev parent reply other threads:[~2024-05-09 17:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 15:01 [PATCH 0/3] more lbs test fixes Pankaj Raghav (Samsung)
2024-05-06 15:01 ` [PATCH 1/3] xfs/161: adapt the test case for 64k FS blocksize Pankaj Raghav (Samsung)
2024-05-07 22:23 ` Darrick J. Wong
2024-05-08 2:50 ` Ritesh Harjani
2024-05-08 16:06 ` Darrick J. Wong
2024-05-09 13:01 ` Pankaj Raghav (Samsung)
2024-05-08 10:58 ` Pankaj Raghav (Samsung)
2024-05-08 14:49 ` Pankaj Raghav (Samsung)
2024-05-09 17:33 ` Ritesh Harjani [this message]
2024-05-06 15:01 ` [PATCH 2/3] generic/436: round up bufsz to nearest filesystem blksz Pankaj Raghav (Samsung)
2024-05-07 18:10 ` Zorro Lang
2024-05-07 22:24 ` Darrick J. Wong
2024-05-08 10:05 ` Pankaj Raghav (Samsung)
2024-05-06 15:01 ` [PATCH 3/3] xfs/008: use block size instead of the pagesize Pankaj Raghav (Samsung)
2024-05-07 18:10 ` Zorro Lang
2024-05-11 5:04 ` [PATCH 0/3] more lbs test fixes Zorro Lang
-- strict thread matches above, loose matches on Subject: below --
2024-05-07 4:00 [PATCH 1/3] xfs/161: adapt the test case for 64k FS blocksize Ritesh Harjani
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=87ttj6gaaz.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