All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill O'Donnell <bodonnel@redhat.com>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org, linux-bcachefs@vger.kernel.org
Subject: Re: [PATCH v2] generic/459: improve shutdown/read-only check to accommodate bcachefs
Date: Wed, 29 Nov 2023 15:36:43 -0600	[thread overview]
Message-ID: <ZWeu623M2xNW7IlH@redhat.com> (raw)
In-Reply-To: <20231129201614.347901-1-bfoster@redhat.com>

On Wed, Nov 29, 2023 at 03:16:14PM -0500, Brian Foster wrote:
> generic/459 occasionally fails on bcachefs because the deliberately
> induced I/O errors caused by exhausting the overprovisioned thin
> pool can lead to filesystem shutdown. This test considers this
> expected behavior on certain fs', but only checks for the ext4
> remount read-only behavior. bcachefs does a similar emergency
> read-only transition in response to certain I/O errors, but it
> behaves more similar to an XFS shutdown and doesn't necessarily
> reflect "ro" state in the mount table (unless induced by userspace).
> 
> Since the test already runs a touch command to help trigger the ext4
> error handling sequence, this can be tweaked to serve double duty
> and also more accurately detect read-only status on bcachefs.
> Refactor into a small helper, check for touch command failure, and
> consider the fs read-only if either that or the mount entry check
> indicates it.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>

Looks fine.

Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>

> ---
> 
> v2:
> - Drop error filtering and just check touch failure.
> - Comment tweaks.
> v1: https://lore.kernel.org/fstests/20231117144317.10882-1-bfoster@redhat.com/
> 
>  tests/generic/459 | 28 +++++++++++++++++++++-------
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/generic/459 b/tests/generic/459
> index 4dd7a43b..c3f0b2b0 100755
> --- a/tests/generic/459
> +++ b/tests/generic/459
> @@ -57,6 +57,24 @@ origpsize=200
>  virtsize=300
>  newpsize=300
>  
> +# Check whether the filesystem has shutdown or remounted read-only. Shutdown
> +# behavior can differ based on filesystem and configuration. Some fs' may not
> +# have remounted without an additional write while others may have shutdown but
> +# do not necessarily reflect read-only state in the mount options. Check both
> +# here by first trying a simple write and following with an explicit ro check.
> +is_shutdown_or_ro()
> +{
> +	ro=0
> +
> +	# if the fs has not shutdown, this may help trigger a remount-ro
> +	touch $SCRATCH_MNT/newfile > /dev/null 2>&1 || ro=1
> +
> +	_fs_options /dev/mapper/$vgname-$snapname | grep -w "ro" > /dev/null
> +	[ $? == 0 ] && ro=1
> +
> +	echo $ro
> +}
> +
>  # Ensure we have enough disk space
>  _scratch_mkfs_sized $((350 * 1024 * 1024)) >>$seqres.full 2>&1
>  
> @@ -113,13 +131,9 @@ ret=$?
>  #	- The filesystem stays in Read-Write mode, but can be frozen/thawed
>  #	  without getting stuck.
>  if [ $ret -ne 0 ]; then
> -	# freeze failed, filesystem should reject further writes and remount
> -	# as readonly. Sometimes the previous write process won't trigger
> -	# ro-remount, e.g. on ext3/4, do additional touch here to make sure
> -	# filesystems see the metadata I/O error.
> -	touch $SCRATCH_MNT/newfile >/dev/null 2>&1
> -	ISRO=$(_fs_options /dev/mapper/$vgname-$snapname | grep -w "ro")
> -	if [ -n "$ISRO" ]; then
> +	# freeze failed, filesystem should reject further writes
> +	ISRO=`is_shutdown_or_ro`
> +	if [ $ISRO == 1 ]; then
>  		echo "Test OK"
>  	else
>  		echo "Freeze failed and FS isn't Read-Only. Test Failed"
> -- 
> 2.41.0
> 
> 


      reply	other threads:[~2023-11-29 21:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 20:16 [PATCH v2] generic/459: improve shutdown/read-only check to accommodate bcachefs Brian Foster
2023-11-29 21:36 ` Bill O'Donnell [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=ZWeu623M2xNW7IlH@redhat.com \
    --to=bodonnel@redhat.com \
    --cc=bfoster@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-bcachefs@vger.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 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.