FS/XFS testing framework
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
	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: Wed, 8 May 2024 09:06:27 -0700	[thread overview]
Message-ID: <20240508160627.GG360908@frogsfrogsfrogs> (raw)
In-Reply-To: <CALk7dXqCD2MDPavit0mkD061bEHTswFxuwbfPZuAuCtNcFAPFA@mail.gmail.com>

On Wed, May 08, 2024 at 08:20:01AM +0530, Ritesh Harjani wrote:
> On Wed, May 8, 2024 at 3:53 AM Darrick J. Wong <djwong@kernel.org> 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.
> 
> Maybe we should improve this comment to -
> 
> # Write more than the soft block quota limit of 12k which is set later
> via xfs_quota
> # On 64k bs this will get rounded to the nearest blocksize which is 64k
> 
> > > +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 guess it won't (even for bs=4k), because we set the bsoft=12k via xfs_quota.
> So we have to write more than 12k to trigger the grace timer.

Ah, ok.  Yes, that makes sense with the improved comment. :)

--D

> -ritesh
> 

  reply	other threads:[~2024-05-08 16:06 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 [this message]
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
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=20240508160627.GG360908@frogsfrogsfrogs \
    --to=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=ritesh.list@gmail.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