From patchwork Wed Jul 28 00:09:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12404695 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B07E3C4338F for ; Wed, 28 Jul 2021 00:09:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8954960F6B for ; Wed, 28 Jul 2021 00:09:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232840AbhG1AJo (ORCPT ); Tue, 27 Jul 2021 20:09:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:56156 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232731AbhG1AJo (ORCPT ); Tue, 27 Jul 2021 20:09:44 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 846F960F23; Wed, 28 Jul 2021 00:09:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627430983; bh=l25hCtwPmaZVMKa26qzIVvFnfRrLE3HV4QrZjUsSPRs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=gFqPaDBtCThepG5KEOdPmOTJA33q0e7zs6LmHErIxRlxhFkgbX4POhXVEt3dcgd3l q65bweWKGh8mx5mENe/xirCsUJliV7g+C9pemt0yIE7dciiPHhr5rVfKzQaucwrjjB zfz7tah9Todhk6iE2G+n6YDmHxdxFffxEY8KC/yt4pNu4kRDHsfna8T43NfSo7wOWR q09RIvQO4qEs2z56NocqzBMqw0pr/VfVbgHYBS9Tj9O6ia70/uoI+3nD0Hm0725zSL K1KQCblVIMdznIiAu1V3z7wbiqm1/OTMFQYk4HpvSR195i8M27vHffRr7X/22Tb1s9 2rQKcsRVKq9IQ== Subject: [PATCH 1/4] xfs/106: fix golden output regression in quota off test From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Tue, 27 Jul 2021 17:09:43 -0700 Message-ID: <162743098324.3427426.13889210606647869531.stgit@magnolia> In-Reply-To: <162743097757.3427426.8734776553736535870.stgit@magnolia> References: <162743097757.3427426.8734776553736535870.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong In commit 4c5df338, we reshuffled this test a bit in preparation to disable quotaoff by rearranging the test to testing disabling of quota by remounting the filesystem. Unfortunately, extra blank lines were added to the golden output, leading to test regressions. The "extra" blank lines are a result of the "echo ; test_off"; test_off() itself doesn't print anything. Make it print /something/ so that we know what the test was trying to do when a particular line of golden output appears, then fix the blank lines. Fixes: 4c5df338 ("xfs/106: don't test disabling quota accounting") Signed-off-by: Darrick J. Wong --- tests/xfs/106 | 1 + tests/xfs/106.out | 5 +++++ 2 files changed, 6 insertions(+) diff --git a/tests/xfs/106 b/tests/xfs/106 index d8f55441..fc2281af 100755 --- a/tests/xfs/106 +++ b/tests/xfs/106 @@ -155,6 +155,7 @@ test_enable() test_off() { + echo "turning quota off by remounting" _scratch_unmount _qmount_option "" _qmount diff --git a/tests/xfs/106.out b/tests/xfs/106.out index 3e6805a6..7c7be6b1 100644 --- a/tests/xfs/106.out +++ b/tests/xfs/106.out @@ -149,6 +149,7 @@ Blocks grace time: [3 days] Inodes grace time: [3 days] Realtime Blocks grace time: [7 days] +turning quota off by remounting checking remove command (type=u) User quota are not enabled on SCRATCH_DEV @@ -327,6 +328,8 @@ Blocks grace time: [3 days] Inodes grace time: [3 days] Realtime Blocks grace time: [7 days] +turning quota off by remounting + checking remove command (type=g) Group quota are not enabled on SCRATCH_DEV @@ -504,6 +507,8 @@ Blocks grace time: [3 days] Inodes grace time: [3 days] Realtime Blocks grace time: [7 days] +turning quota off by remounting + checking remove command (type=p) Project quota are not enabled on SCRATCH_DEV From patchwork Wed Jul 28 00:09:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12404697 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1298DC4338F for ; Wed, 28 Jul 2021 00:09:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ECA2860F41 for ; Wed, 28 Jul 2021 00:09:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232926AbhG1AJu (ORCPT ); Tue, 27 Jul 2021 20:09:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:56188 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232731AbhG1AJt (ORCPT ); Tue, 27 Jul 2021 20:09:49 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0A5A160F23; Wed, 28 Jul 2021 00:09:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627430989; bh=sUl+vwkzYrngHgPfrD1QGpBmluw9ukUuKF2ryaErny0=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=KmYoPkyA3sPN1qA3WtWxkpQ3LtKMdydbTGKRbqA6T2FbSE9ox0qRtz4+CmeeHLbAm gYnUyjTBesKCm0MmsYQb9ikmXY1kNyA4ZB1+PNBQqwkGecRE9RxN8P/49WQUOeel+R 8EGDrq+WupuLrZpbWdgkVKhktCNkDrSyrHnz3QAV3u2j2vGshrFK9fLxpawm+jLGLJ 55ZzdZdmUGIoePlbgf87V2sQlW7omztDoSFGxVvMCv6+dz6CI1+OBdODaeU6AMTSiy 2CtmuOJJzj4NDq9GadKlslkfqgqscMd86OH9/aX3tcRyQDeKFcBhz9qd/8YCkUdRCj Uo8UT4Fy3Uhcg== Subject: [PATCH 2/4] check: don't leave the scratch filesystem mounted after _notrun From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Tue, 27 Jul 2021 17:09:48 -0700 Message-ID: <162743098874.3427426.3383033227839715899.stgit@magnolia> In-Reply-To: <162743097757.3427426.8734776553736535870.stgit@magnolia> References: <162743097757.3427426.8734776553736535870.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong Unmount the scratch filesystem if a test decides to _notrun itself because _try_wipe_scratch_devs will not be able to wipe the scratch device prior to the next test run. We don't want to let scratch state from one test leak into subsequent tests if we can help it. Signed-off-by: Darrick J. Wong --- check | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/check b/check index bb7e030c..5d71b74c 100755 --- a/check +++ b/check @@ -871,6 +871,11 @@ function run_section() notrun="$notrun $seqnum" n_notrun=`expr $n_notrun + 1` tc_status="notrun" + + # Unmount the scratch fs so that we can wipe the scratch + # dev state prior to the next test run. + _scratch_unmount 2> /dev/null + rm -f ${RESULT_DIR}/require_scratch* continue; fi From patchwork Wed Jul 28 00:09:54 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12404699 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A3A5C4338F for ; Wed, 28 Jul 2021 00:09:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 75A7F60F6B for ; Wed, 28 Jul 2021 00:09:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232778AbhG1AJz (ORCPT ); Tue, 27 Jul 2021 20:09:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:56228 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232731AbhG1AJz (ORCPT ); Tue, 27 Jul 2021 20:09:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7FA1560F23; Wed, 28 Jul 2021 00:09:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627430994; bh=Go/IC1+fJQ5/TmdLQ4XtoXYNyUqRVM/+6+aFxKErH6M=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=hLNlYmjibQyzxbQsIilPviu1UqPH+ro7/ESPzfrBDhW4JvlvgSFrCuynOoY1F9ukC 9fWbjXAy3OYzcHlxTBojC179vBRnZiiO7EqsBmpK/EAKC/NsDftQ/dbqwxYombeWpV v6aHnFHk8OCI3+Mo+MNb3G0OXDRnl0gOqmmcKjXUcVc8kk85ZDMFrBIwU5uTfbzIkU A3szUFC1k5f+rPcLIEFgehlS4XNDzaZ44TQAQME7TTrIuzxKivazWs0fuN6R2B4anP FA3EmXi/HheoUBFJGHtZmglEelIhr73vwc2gIpOZQoZFosVXhNIdSSecp9Lets6U/C QqOc4aKcUQ4/Q== Subject: [PATCH 3/4] generic/570: fix regression when SCRATCH_DEV is still formatted From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Tue, 27 Jul 2021 17:09:54 -0700 Message-ID: <162743099423.3427426.15112820532966726474.stgit@magnolia> In-Reply-To: <162743097757.3427426.8734776553736535870.stgit@magnolia> References: <162743097757.3427426.8734776553736535870.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong Newer versions of mkswap (or at least the one in util-linux 2.34) complain to stderr when they're formatting over a device that seems to contain existing data: mkswap: /dev/sdf: warning: wiping old btrfs signature. This is harmless (since the swap image does get written!) but the extra golden output is flagged as a regression. Update the mkswap usage in this test to dump the stderr output to $seqres.full, and complain if the exit code is nonzero. This fixes a regression that the author noticed when testing btrfs and generic/507 and generic/570 run sequentially. generic/507 calls _require_scratch_shutdown to see if the shutdown call is supported. btrfs does not support that, so the test is _notrun. This leaves the scratch filesystem mounted, causing the _try_wipe_scratch_devs between tests to fail. When g/570 starts up, the scratch device still contains leftovers from the failed attempt to run g/507, which is why the mkswap command outputs the above warning. Signed-off-by: Darrick J. Wong --- tests/generic/570 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/generic/570 b/tests/generic/570 index 7d03acfe..02c1d333 100755 --- a/tests/generic/570 +++ b/tests/generic/570 @@ -27,7 +27,7 @@ _require_scratch_nocheck _require_block_device $SCRATCH_DEV test -e /dev/snapshot && _notrun "userspace hibernation to swap is enabled" -$MKSWAP_PROG "$SCRATCH_DEV" >> $seqres.full +$MKSWAP_PROG -f "$SCRATCH_DEV" &>> $seqres.full || echo "mkswap failed?" # Can you modify the swap dev via previously open file descriptors? for verb in 1 2 3 4; do From patchwork Wed Jul 28 00:09:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12404701 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14C5BC4338F for ; Wed, 28 Jul 2021 00:10:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ECA6A60F41 for ; Wed, 28 Jul 2021 00:10:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232731AbhG1AKB (ORCPT ); Tue, 27 Jul 2021 20:10:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:56256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232989AbhG1AKA (ORCPT ); Tue, 27 Jul 2021 20:10:00 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 090CB60F23; Wed, 28 Jul 2021 00:10:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627431000; bh=Wcmka2eSmM+Ej7XogJjxoBbCS/nbr11GK7b8/d/Fdmo=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Xjhn9r790tLjxOSRM3etlbnO1JR6nYPSUBf2sWJlEY3IN77sW42AY9g6uvPMy4x5u ROHMCvpMkQyOfkfs+GjFwS+/Qg4Fa1Xt+r8ysvlyPqFoFTjaEcRCZVkt+VIk2j64zs 3WisDfmAEdaVI3LxmQ3SC7mSExYgHmOUXOhg8VRFYS6Aro4HyT7hbiDVGMprwpfTJi gyx5X5bK0eqgS33hI7cMCaUtCjBwf39b44mRe+/4+BTd01uwDJlcHVzdyeS1CczAa7 RqZZ5pXu7TJeNQBJXpDYjod/W1fCEG1zXlVBsEIsBirqUq8phZ9+HL3+dR4j4D7xPi H8b6KXeu+mw9w== Subject: [PATCH 4/4] check: back off the OOM score adjustment to -500 From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Tue, 27 Jul 2021 17:09:59 -0700 Message-ID: <162743099972.3427426.5759542449674461731.stgit@magnolia> In-Reply-To: <162743097757.3427426.8734776553736535870.stgit@magnolia> References: <162743097757.3427426.8734776553736535870.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong Dave Chinner complained that fstests really shouldn't be running at -1000 oom score adjustment because that makes it more "important" than certain system daemons (e.g. journald, udev). That's true, so increase it to -500. Signed-off-by: Darrick J. Wong --- check | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/check b/check index 5d71b74c..e493ca11 100755 --- a/check +++ b/check @@ -564,7 +564,7 @@ OOM_SCORE_ADJ="/proc/self/oom_score_adj" function _adjust_oom_score() { test -w "${OOM_SCORE_ADJ}" && echo "$1" > "${OOM_SCORE_ADJ}" } -_adjust_oom_score -1000 +_adjust_oom_score -500 # ...and make the tests themselves somewhat more attractive to it, so that if # the system runs out of memory it'll be the test that gets killed and not the From patchwork Wed Jul 28 20:00:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12406661 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 112B6C432BE for ; Wed, 28 Jul 2021 20:00:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DC2A361040 for ; Wed, 28 Jul 2021 20:00:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230406AbhG1UAW (ORCPT ); Wed, 28 Jul 2021 16:00:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:47974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230125AbhG1UAW (ORCPT ); Wed, 28 Jul 2021 16:00:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7E01C61038; Wed, 28 Jul 2021 20:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627502420; bh=hEMHdCa2sZ3N0F5WKnDb6naLlwS4erOTjOuNqGKDpoE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Kg9UjLVXAjVsvW9WLUhU8H3LS1DBK1dtDJkQwIb6n3Ss6eMoUMxWVW08iHG3pWdDc Nv/tRhnZY2cjvbgd5Ltt8zbWDmA4pyPwchv+QHHfZUyoZ5eR5dLb85LJK9lyiP6mqW K9/rYlgg1XwAA+esijqYC2oDWbNM69sJAd5uE1hbvzhXj0fb8Kfa9Z8swJr18OEvT/ Sb9Y6Jw4apJdqrZJWXSXjpyPGqdUJkOuqVcDD5K0rRdbtWUh7IPgfjx1d+wbDW56Gy OcOwdf0TPsiwLHj9ugr3SY6F9tMdCJb+AnyrNIlIJEGNOnjbyt31N/oE/ZFQBWsCcK 4BabOc+yUfvsQ== Date: Wed, 28 Jul 2021 13:00:20 -0700 From: "Darrick J. Wong" To: guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me, chandanrlinux@gmail.com Subject: [PATCH 5/4] xfs/530: skip test if user MKFS_OPTIONS screw up formatting Message-ID: <20210728200020.GA3601425@magnolia> References: <162743097757.3427426.8734776553736535870.stgit@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <162743097757.3427426.8734776553736535870.stgit@magnolia> Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong Skip this test if the user's MKFS_OPTIONS are not compatible with the realtime parameters that we're injecting in order to test growfs bugs. Because this test is trying to trigger a specific kernel bug, we need mkfs to format a filesystem with very specific geometry parameters. The first problem stems from the fact that the test performs a default mkfs, computes a suitable realtime geometry from that filesystem, and then formats a second time with an explicit blocksize option to mkfs. If the original MKFS_OPTS contained a blocksize directive, the mkfs will fail because the option was respecified. The two blocksize options will be the same, so we drop the explicit blocksize option. However, this exposes a second problem: MKFS_OPTIONS might contain options that are not compatible with any realtime filesystem. If that happens, _scratch_do_mkfs will "helpfully" drop MKFS_OPTIONS and try again with only the options specified by the test. This gets us a filesystem with the given rt geometry, but it could be missing critical parameters from MKFS_OPTIONS (like blocksize). The test will then fail to exercise the growfs bugfix, so the second part of the fix is to check that the filesystem we're going to test actually has the geometry parameters that we require. Signed-off-by: Darrick J. Wong Reviewed-by: Chandan Babu R --- tests/xfs/530 | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/tests/xfs/530 b/tests/xfs/530 index 99a4d33b..0e12422d 100755 --- a/tests/xfs/530 +++ b/tests/xfs/530 @@ -60,10 +60,22 @@ echo "Format and mount rt volume" export USE_EXTERNAL=yes export SCRATCH_RTDEV=$rtdev -_scratch_mkfs -d size=$((1024 * 1024 * 1024)) -b size=${dbsize} \ +_scratch_mkfs -d size=$((1024 * 1024 * 1024)) \ -r size=${rtextsz},extsize=${rtextsz} >> $seqres.full _try_scratch_mount || _notrun "Couldn't mount fs with synthetic rt volume" +# If we didn't get the desired realtime volume and the same blocksize as the +# first format (which we used to compute a specific rt geometry), skip the +# test. This can happen if the MKFS_OPTIONS conflict with the ones we passed +# to _scratch_mkfs or do not result in a valid rt fs geometry. In this case, +# _scratch_mkfs will try to "succeed" at formatting by dropping MKFS_OPTIONS, +# giving us the wrong geometry. +formatted_blksz="$(_get_block_size $SCRATCH_MNT)" +test "$formatted_blksz" -ne "$dbsize" && \ + _notrun "Tried to format with $dbsize blocksize, got $formatted_blksz." +$XFS_INFO_PROG $SCRATCH_MNT | egrep -q 'realtime.*blocks=0' && \ + _notrun "Filesystem should have a realtime volume" + echo "Consume free space" fillerdir=$SCRATCH_MNT/fillerdir nr_free_blks=$(stat -f -c '%f' $SCRATCH_MNT) From patchwork Wed Jul 28 20:00:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12406663 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A1D2C4338F for ; Wed, 28 Jul 2021 20:00:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0D08761042 for ; Wed, 28 Jul 2021 20:00:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230502AbhG1UAs (ORCPT ); Wed, 28 Jul 2021 16:00:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:48048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230125AbhG1UAs (ORCPT ); Wed, 28 Jul 2021 16:00:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3BBC761038; Wed, 28 Jul 2021 20:00:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627502446; bh=vgthiiJorC0JS1GUWSVhqMCItufbfTh0HlZC9e3yJZQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L5nmZn6FtlHOWqx/5nHvLYCq1P7tvucSw+jxR/cQB/IE0XoLCzds5xJ+pIpMco4Q2 pAf3Aw2dFHiupslxrKHg/9gQB7yYk7aYyEsFwLWynGUKwsXvRCxrMapUgb/TRZcQ8L oIHgrWhypZ8byERlILSoH5eMgd+JBUY3rtKKq8RPzsnwS5S2sdetAXYeJIV88jX7pr DcEczoFSt3FKwzkUQlEOlEY9UBunSGpyXAbdQXjlGIt2HrobHg4NvyaKS0PHnh2yRe 4aHuGQ9gJYcjuqgPX5ILNa4EtneXL3NpiRpsPP3Vok9L3m4VJJlSsZz1M8I7+2kYL1 bUW/lr3Ag0LLg== Date: Wed, 28 Jul 2021 13:00:45 -0700 From: "Darrick J. Wong" To: guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me, Christoph Hellwig Subject: [PATCH 6/4] xfs/007: fix regressions on V4 filesystems Message-ID: <20210728200045.GB3601425@magnolia> References: <162743097757.3427426.8734776553736535870.stgit@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <162743097757.3427426.8734776553736535870.stgit@magnolia> Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong Following commit eae40404, I noticed the following regression when running a V4 fstests run on an 5.13 kernel: --- /tmp/fstests/tests/xfs/007.out 2021-05-13 11:47:55.793859995 -0700 +++ /var/tmp/fstests/xfs/007.out.bad 2021-07-28 09:23:42.856000000 -0700 @@ -16,4 +16,4 @@ *** umount *** Usage after quotarm *** core.nblocks = 0 -core.nblocks = 0 +core.nblocks = 1 The underlying cause of this problem is the fact that we now remount the filesystem with no quota options because that will (soon) become the only means to turn off quota accounting on XFS. Because V4 filesystems don't support simultaneous project and group quotas and play weird remapping games with the incore superblock field, we actually have to issue a remove command for the group quota file if we're trying to truncate the project quota file on a V4 filesystem. Due to stupid limitations in xfs_quota we actually have to issue a separate 'remove' command. Fixes: eae40404 ("xfs/007: unmount after disabling quota") Signed-off-by: Darrick J. Wong --- tests/xfs/007 | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/tests/xfs/007 b/tests/xfs/007 index 796db960..6d6d828b 100755 --- a/tests/xfs/007 +++ b/tests/xfs/007 @@ -43,10 +43,27 @@ do_test() _qmount echo "*** turn off $off_opts quotas" $XFS_QUOTA_PROG -x -c "off -$off_opts" $SCRATCH_MNT + + # Remount the filesystem with no quota options to force quotas off. + # This takes care of newer kernels where quotaoff clears the superblock + # quota enforcement flags but doesn't shut down accounting. _scratch_unmount _qmount_option "" _scratch_mount - $XFS_QUOTA_PROG -x -c "remove -$off_opts" $SCRATCH_MNT + + rm_commands=(-x -c "remove -$off_opts") + + # Remounting a V4 fs with no quota options means that the internal + # gquotino -> pquotino remapping does not happen. If we want to + # truncate the "project" quota file we must run remove -g. However, + # xfs_quota has a nasty sharp edge wherein passing '-g' and '-p' only + # results in a QUOTARM call for the group quota file, so we must make + # a separate remove call. + [ $_fs_has_crcs == 0 ] && [ "$off_opts" = "up" ] && \ + rm_commands+=(-c "remove -g") + + $XFS_QUOTA_PROG "${rm_commands[@]}" $SCRATCH_MNT + echo "*** umount" _scratch_unmount