All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Pankaj Raghav <p.raghav@samsung.com>
Cc: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
	zlang@redhat.com, fstests@vger.kernel.org, mcgrof@kernel.org,
	gost.dev@samsung.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/2] xfs/558: scale blk IO size based on the filesystem blksz
Date: Wed, 13 Mar 2024 13:08:34 -0700	[thread overview]
Message-ID: <20240313200834.GP1927156@frogsfrogsfrogs> (raw)
In-Reply-To: <cb8a9359-6678-4692-a76c-545f8bb44b00@samsung.com>

On Mon, Jan 22, 2024 at 06:23:16PM +0100, Pankaj Raghav wrote:
> On 22/01/2024 17:53, Darrick J. Wong wrote:
> > On Mon, Jan 22, 2024 at 12:17:50PM +0100, Pankaj Raghav (Samsung) wrote:
> >> From: Pankaj Raghav <p.raghav@samsung.com>
> >>
> >> This test fails for >= 64k filesystem block size on a 4k PAGE_SIZE
> >> system(see LBS efforts[1]). Scale the `blksz` based on the filesystem
> > > Fails how, specifically?
> 
> I basically get this in 558.out.bad when I set filesystem block size to be 64k:
> QA output created by 558
> Expected to hear about writeback iomap invalidations?
> Silence is golden
> 
> But I do see that iomap invalidations are happening for 16k and 32k, which makes it pass
> the test for those block sizes.
> 
> My suspicion was that we don't see any invalidations because of the blksz fixed
> at 64k in the test, which will contain one FSB in the case of 64k block size.
> 
> Let me know if I am missing something.

Nope, that sounds good and fixes the problems I saw.  So:
Tested-by: Darrick J. Wong <djwong@kernel.org>

And if you add to the commit message that this test specifically fixes
the "Expected to hear about writeback iomap invalidations?" message for
64k filesystems, then:
Reviewed-by: Darrick J. Wong <djwong@kernel.org>

--D

> > 
> > --D
> > 
> >> block size instead of fixing it as 64k so that we do get some iomap
> >> invalidations while doing concurrent writes.
> >>
> >> Cap the blksz to be at least 64k to retain the same behaviour as before
> >> for smaller filesystem blocksizes.
> >>
> >> [1] LBS effort: https://lore.kernel.org/lkml/20230915183848.1018717-1-kernel@pankajraghav.com/
> >>
> >> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
> >> ---
> >>  tests/xfs/558 | 7 ++++++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tests/xfs/558 b/tests/xfs/558
> >> index 9e9b3be8..270f458c 100755
> >> --- a/tests/xfs/558
> >> +++ b/tests/xfs/558
> >> @@ -127,7 +127,12 @@ _scratch_mount >> $seqres.full
> >>  $XFS_IO_PROG -c 'chattr -x' $SCRATCH_MNT &> $seqres.full
> >>  _require_pagecache_access $SCRATCH_MNT
> >>  
> >> -blksz=65536
> >> +min_blksz=65536
> >> +file_blksz=$(_get_file_block_size "$SCRATCH_MNT")
> >> +blksz=$(( 8 * $file_blksz ))
> >> +
> >> +blksz=$(( blksz > min_blksz ? blksz : min_blksz ))
> >> +
> >>  _require_congruent_file_oplen $SCRATCH_MNT $blksz
> >>  
> >>  # Make sure we have sufficient extent size to create speculative CoW
> >> -- 
> >> 2.43.0
> >>
> 

  reply	other threads:[~2024-03-13 20:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 11:17 [PATCH 0/2] fstest changes for LBS Pankaj Raghav (Samsung)
2024-01-22 11:17 ` [PATCH 1/2] xfs/558: scale blk IO size based on the filesystem blksz Pankaj Raghav (Samsung)
2024-01-22 16:53   ` Darrick J. Wong
2024-01-22 17:23     ` Pankaj Raghav
2024-03-13 20:08       ` Darrick J. Wong [this message]
2024-01-22 11:17 ` [PATCH 2/2] xfs/161: adapt the test case for LBS filesystem Pankaj Raghav (Samsung)
2024-01-22 16:57   ` Darrick J. Wong
2024-01-22 17:32     ` Pankaj Raghav
2024-01-25 16:06     ` Pankaj Raghav
2024-01-23  0:25 ` [PATCH 0/2] fstest changes for LBS Dave Chinner
2024-01-23  8:52   ` Pankaj Raghav
2024-01-23 13:43     ` Zorro Lang
2024-01-23 15:39       ` Ritesh Harjani
2024-01-23 16:33       ` Pankaj Raghav
2024-01-23 15:35     ` Ritesh Harjani
2024-01-23 16:40       ` Pankaj Raghav
2024-01-23 19:42         ` Ritesh Harjani
2024-01-23 20:21           ` Pankaj Raghav
2024-01-24 16:58             ` Darrick J. Wong
2024-01-24 21:06               ` Pankaj Raghav

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=20240313200834.GP1927156@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=kernel@pankajraghav.com \
    --cc=linux-xfs@vger.kernel.org \
    --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 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.