From patchwork Wed Dec 13 22:34:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13491951 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00BD7224E8; Wed, 13 Dec 2023 22:34:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eL3qIiF5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66805C433C9; Wed, 13 Dec 2023 22:34:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702506874; bh=89Fy9l4esXv0SvZBb/ocuRDW3q9+FBxPqtqzwWY3WpE=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=eL3qIiF5b/sVRE9ge0fSer6M87vnUYBpDKKCehTZkGhG7ESqMIYrWmk3O5xvB7C1i OEQDPo2eJ3RwH5lgS7dfDMz3W8MT+KGgJdbAxXAN06eh1pYnWpD4TzarA+O0c3lweP KCSVInDuU736neoURk1JHfHHMvfZkBtD7ArFb8eVG1++BV+HYEg/iLiCnau7Bgk/8Z kalD5yrSallnLHXCFxj8K9Oh81XeekVZb9+sKr+CoZf5DO1Jk6iv/1UzwYjhCRe0F5 bUbB2lM5EJLxbiWR8Z0z80+ptrXjQIdFcxXOjRzQhqc9wTknWAHhfWu5l6JxFeQ54s L6mKsNABqQRZg== Subject: [PATCH 1/3] generic/615: fix loop termination failures From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: guan@eryu.me, fstests@vger.kernel.org, linux-xfs@vger.kernel.org Date: Wed, 13 Dec 2023 14:34:33 -0800 Message-ID: <170250687380.1363584.4078567385149829394.stgit@frogsfrogsfrogs> In-Reply-To: <170250686802.1363584.16475360795139585624.stgit@frogsfrogsfrogs> References: <170250686802.1363584.16475360795139585624.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong On 6.7-rc2, I've noticed that this test hangs unpredictably because the stat loop fails to exit. While the kill $loop_pid command /should/ take care of it, it clearly isn't. Set up an additional safety factor by checking for the existence of a sentinel flag before starting the loop body. In bash, "[" is a builtin so the loop should run almost as tightly as it did before. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- tests/generic/615 | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/generic/615 b/tests/generic/615 index 4979306d56..9411229874 100755 --- a/tests/generic/615 +++ b/tests/generic/615 @@ -21,11 +21,10 @@ _require_odirect stat_loop() { - trap "wait; exit" SIGTERM local filepath=$1 local blocks - while :; do + while [ -e "$loop_file" ]; do blocks=$(stat -c %b $filepath) if [ $blocks -eq 0 ]; then echo "error: stat(2) reported zero blocks" @@ -39,6 +38,8 @@ _scratch_mount $XFS_IO_PROG -f -s -c "pwrite -b 64K 0 64K" $SCRATCH_MNT/foo > /dev/null +loop_file=$tmp.loopfile +touch $loop_file stat_loop $SCRATCH_MNT/foo & loop_pid=$! @@ -64,6 +65,7 @@ for ((i = 0; i < 2000; i++)); do $XFS_IO_PROG -d -c "pwrite -b 64K 0 64K" $SCRATCH_MNT/foo > /dev/null done +rm -f $loop_file kill $loop_pid &> /dev/null wait From patchwork Wed Dec 13 22:34:39 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13491952 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C791224E8; Wed, 13 Dec 2023 22:34:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qrUqOhhI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B676C433C7; Wed, 13 Dec 2023 22:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702506880; bh=+cSw5p+7uvHF78olMTp+YdaRZOGROXOa64Wx3n+65+Y=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=qrUqOhhIwmdYC5nKXgTredjMWfeDtwvrCdEzbv7OnPlKM/NSi+ZBFDCr07vxntYNf pw6QOtQZ/hai4YiyxeZh6TekTsJ9jlTxd835c8CYzKwqR7cYLTCwL06GSGBaFXglOh ogdsiGLx6Rizisxb4l07b7+Ee0VDUuwxFH/4HXerKxOM4baAELpK8AtfKLrv6vWGg1 WpquCBDR6m6cQ0gt8WTIOhMv+sWjPvrVWxokNDQfw3bduAgQzbe8KeAfhE1xnnjzYt su3i28cafn9bWU8zODJ5my0Pu6k2XL+KXnY3YjGbUVPP5mPB8e13TdiYDlW8ox7AfL WyYgckDf1IuRA== Subject: [PATCH 2/3] generic/410: don't blow away seqres.full during test From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: guan@eryu.me, fstests@vger.kernel.org, linux-xfs@vger.kernel.org Date: Wed, 13 Dec 2023 14:34:39 -0800 Message-ID: <170250687956.1363584.15519840736150289118.stgit@frogsfrogsfrogs> In-Reply-To: <170250686802.1363584.16475360795139585624.stgit@frogsfrogsfrogs> References: <170250686802.1363584.16475360795139585624.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Don't truncate $seqres.full every time we format a new filesystem; this makes debugging of this weird failure: Reviewed-by: Christoph Hellwig --- /tmp/fstests/tests/generic/410.out 2023-07-11 12:18:21.642971022 -0700 +++ /var/tmp/fstests/generic/410.out.bad 2023-11-29 01:13:00.020000000 -0800 @@ -107,6 +107,9 @@ mpB/dir SCRATCH_DEV mpC SCRATCH_DEV mpC/dir SCRATCH_DEV ====== +mkdir: cannot create directory '/mnt/410/3871733_mpA': File exists +mkdir: cannot create directory '/mnt/410/3871733_mpB': File exists +mkdir: cannot create directory '/mnt/410/3871733_mpC': File exists make-shared a slave shared mount before make-shared run on slave shared ------ nearly impossible. Signed-off-by: Darrick J. Wong --- tests/generic/410 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/generic/410 b/tests/generic/410 index 8cc36d9f38..5fb5441a0c 100755 --- a/tests/generic/410 +++ b/tests/generic/410 @@ -93,7 +93,7 @@ start_test() { local type=$1 - _scratch_mkfs >$seqres.full 2>&1 + _scratch_mkfs >>$seqres.full 2>&1 _get_mount -t $FSTYP $SCRATCH_DEV $MNTHEAD $MOUNT_PROG --make-"${type}" $MNTHEAD mkdir $mpA $mpB $mpC From patchwork Wed Dec 13 22:34:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13491953 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54F17224E8; Wed, 13 Dec 2023 22:34:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mLej5KPg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF8C1C433C8; Wed, 13 Dec 2023 22:34:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702506885; bh=G/r4/NYCYySyRnGiCZ+YcKN390745JqsVNvZUyyM5EM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=mLej5KPgPhMEb4uJ3MzILXS3iXD8XCVqTH0+2Oi3F/eOgqPlugzeh9u78q33xbq/5 tjv3MAM/h+ARah2TybBlwJljDvnzd4FY+6lg7s6aQDXgKsFe3KnujtBlpWd+tslRkO tw4H1VvnxK08mfy3vmI4Ef/JBm1tNBBxbp/6cLVBgIttlBqhVYb3PrMcQnI8d9IK4Q h0asl/ik5PyH0SWm2k4IOmsi2Mq6ueYBjWPsZHafdE+I87JnWYRgr6grl2mR2Xm2M/ N9UmUZU/f9S4fHsX/JOdovYYF0yvhumL8j5Uu6KXhOA4oAIZVwl3zU0FyG/DIClfZb 2v0FSGcTNRnbg== Subject: [PATCH 3/3] generic/735: skip this test if we cannot finsert at pos 1M From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: guan@eryu.me, fstests@vger.kernel.org, linux-xfs@vger.kernel.org Date: Wed, 13 Dec 2023 14:34:45 -0800 Message-ID: <170250688518.1363584.11932716959963736458.stgit@frogsfrogsfrogs> In-Reply-To: <170250686802.1363584.16475360795139585624.stgit@frogsfrogsfrogs> References: <170250686802.1363584.16475360795139585624.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Add a _require_congruent_file_oplen to screen out filesystem configurations that can't start a finsert operation at file pos 1M because the fs block size isn't congruent with 1048576. For example, xfs realtime with 28k rt extents. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- tests/generic/735 | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/generic/735 b/tests/generic/735 index 44b454771d..75b23d5efc 100755 --- a/tests/generic/735 +++ b/tests/generic/735 @@ -25,6 +25,7 @@ dev_size=$((80 * 1024 * 1024)) _scratch_mkfs_sized $dev_size >>$seqres.full 2>&1 || _fail "mkfs failed" _scratch_mount +_require_congruent_file_oplen $SCRATCH_MNT 1048576 # finsert at 1M file_blksz="$(_get_file_block_size ${SCRATCH_MNT})" # Reserve 1M space