Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: fstests@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org, zlang@kernel.org,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [Resend PATCH] generic: test fsync of directory with renamed symlink
Date: Mon, 9 May 2022 11:03:17 +0100	[thread overview]
Message-ID: <20220509100317.GB2270453@falcondesktop> (raw)
In-Reply-To: <8f06924cda35f9a5e22c1c188eb46205dd50491f.1651573756.git.fdmanana@suse.com>

On Tue, May 03, 2022 at 11:57:49AM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> Test that if we fsync a directory, create a symlink inside it, rename
> the symlink, fsync again the directory and then power fail, after the
> filesystem is mounted again, the symlink exists with the new name and
> it has the correct content.
> 
> This currently fails on btrfs, because the symlink ends up empty (which
> is illegal on Linux), but it is fixed by kernel commit:
> 
>     d0e64a981fd841 ("btrfs: always log symlinks in full mode")
> 
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ---
> 
> Resending as this was missed on the last update.
> No changes, only rebased on the current 'for-next' branch.

Zorro,

This missed against the last fstests update.
Did this patch fell through the cracks, or do you expect me to do something about it?

Should I rebase and resend again?

Thanks.

> 
>  tests/generic/690     | 89 +++++++++++++++++++++++++++++++++++++++++++
>  tests/generic/690.out |  2 +
>  2 files changed, 91 insertions(+)
>  create mode 100755 tests/generic/690
>  create mode 100644 tests/generic/690.out
> 
> diff --git a/tests/generic/690 b/tests/generic/690
> new file mode 100755
> index 00000000..0bf47dd7
> --- /dev/null
> +++ b/tests/generic/690
> @@ -0,0 +1,89 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2022 SUSE Linux Products GmbH.  All Rights Reserved.
> +#
> +# FS QA Test 690
> +#
> +# Test that if we fsync a directory, create a symlink inside it, rename the
> +# symlink, fsync again the directory and then power fail, after the filesystem
> +# is mounted again, the symlink exists with the new name and it has the correct
> +# content.
> +#
> +# On btrfs this used to result in the symlink being empty (i_size 0), and it was
> +# fixed by kernel commit:
> +#
> +#    d0e64a981fd841 ("btrfs: always log symlinks in full mode")
> +#
> +. ./common/preamble
> +_begin_fstest auto quick log
> +
> +_cleanup()
> +{
> +	_cleanup_flakey
> +	cd /
> +	rm -r -f $tmp.*
> +}
> +
> +. ./common/rc
> +. ./common/filter
> +. ./common/dmflakey
> +
> +# real QA test starts here
> +
> +_supported_fs generic
> +_require_scratch
> +_require_symlinks
> +_require_dm_target flakey
> +
> +rm -f $seqres.full
> +
> +# f2fs doesn't support fs-op level transaction functionality, so it has no way
> +# to persist all metadata updates in one transaction. We have to use its mount
> +# option "fastboot" so that it triggers a metadata checkpoint to persist all
> +# metadata updates that happen before a fsync call. Without this, after the
> +# last fsync in the test, the symlink named "baz" will not exist.
> +if [ $FSTYP = "f2fs" ]; then
> +	export MOUNT_OPTIONS="-o fastboot $MOUNT_OPTIONS"
> +fi
> +
> +_scratch_mkfs >>$seqres.full 2>&1
> +_require_metadata_journaling $SCRATCH_DEV
> +_init_flakey
> +_mount_flakey
> +
> +# Create our test directory.
> +mkdir $SCRATCH_MNT/testdir
> +
> +# Commit the current transaction and persist the directory.
> +sync
> +
> +# Create a file in the test directory, so that the next fsync on the directory
> +# actually does something (it logs the directory).
> +echo -n > $SCRATCH_MNT/testdir/foo
> +
> +# Fsync the directory.
> +$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir
> +
> +# Now create a symlink inside the test directory.
> +ln -s $SCRATCH_MNT/testdir/foo $SCRATCH_MNT/testdir/bar
> +
> +# Rename the symlink.
> +mv $SCRATCH_MNT/testdir/bar $SCRATCH_MNT/testdir/baz
> +
> +# Fsync again the directory.
> +$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir
> +
> +# Simulate a power failure and then mount again the filesystem to replay the
> +# journal/log.
> +_flakey_drop_and_remount
> +
> +# The symlink should exist, with the name "baz" and its content must be
> +# "$SCRATCH_MNT/testdir/foo".
> +[ -L $SCRATCH_MNT/testdir/baz ] || echo "symlink 'baz' is missing"
> +echo "symlink content: $(readlink $SCRATCH_MNT/testdir/baz | _filter_scratch)"
> +
> +_unmount_flakey
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/generic/690.out b/tests/generic/690.out
> new file mode 100644
> index 00000000..84be1247
> --- /dev/null
> +++ b/tests/generic/690.out
> @@ -0,0 +1,2 @@
> +QA output created by 690
> +symlink content: SCRATCH_MNT/testdir/foo
> -- 
> 2.35.1
> 

  reply	other threads:[~2022-05-09 10:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03 10:57 [Resend PATCH] generic: test fsync of directory with renamed symlink fdmanana
2022-05-09 10:03 ` Filipe Manana [this message]
2022-05-09 11:13   ` Zorro Lang
2022-05-09 11:32     ` Filipe Manana
2022-05-09 13:08       ` Zorro Lang
2022-05-09 12:15 ` David Disseldorp
2022-05-09 12:45   ` Filipe Manana

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=20220509100317.GB2270453@falcondesktop \
    --to=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zlang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox