From patchwork Wed Oct 5 22:30:38 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12999642 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F27AC433FE for ; Wed, 5 Oct 2022 22:30:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229658AbiJEWam (ORCPT ); Wed, 5 Oct 2022 18:30:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229674AbiJEWal (ORCPT ); Wed, 5 Oct 2022 18:30:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1A611DA79; Wed, 5 Oct 2022 15:30:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9CDFC617E2; Wed, 5 Oct 2022 22:30:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04684C433D6; Wed, 5 Oct 2022 22:30:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665009039; bh=kulnfevjQJ7AaDhx8YHjmPALteikCaksoGTJMhyB/+U=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=X9h+nE4s1BZp9tSVbdKmq0pYpqRyAxKdBKhJtdRkFSzQfmWFsvM6anfc/I0/CbDqi Q+GFnGy4N/uxQaAdBB2YUUPIM7Lf6+Ok6S1rQkyXM+QfRIhnWAiCI6A2sFEK1pWvBH nYv0AXcsIHo0foZ6tYg/0zzTuLaa6NepLjivjL2+wmX0zs2SuDvP8JlmU0NwJSRl4C W6jQilU7Rq1sxVdvCv/+HYCiocLl5zm64xiOEmZJqOE8awpygnmEScRf/99SoLMTdi KUn1BNTBreKiUWACpczN6WzsnnrTS353OSS8XqoZKR/CYhgaR3BMpnqzpGmjywlg6m DU7plJejd4Ogw== Subject: [PATCH 1/6] generic/092: skip test if file allocation unit isn't aligned From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Wed, 05 Oct 2022 15:30:38 -0700 Message-ID: <166500903863.886939.16469306626224157289.stgit@magnolia> In-Reply-To: <166500903290.886939.12532028548655386973.stgit@magnolia> References: <166500903290.886939.12532028548655386973.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 This test exercises allocation behavior when truncating a preallocated file down to 5M and then up to 7M. If those two sizes aren't aligned with the file allocation unit length, then the FIEMAP output will show blocks beyond EOF. That will cause trouble with the golden output, so skip this test if that will be the case. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/generic/092 | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tests/generic/092 b/tests/generic/092 index 505e0ec84f..d7c93ca792 100755 --- a/tests/generic/092 +++ b/tests/generic/092 @@ -28,6 +28,12 @@ _require_test _require_xfs_io_command "falloc" _require_xfs_io_command "fiemap" +# If the truncation sizes (5M/7M) aren't aligned with the file allocation unit +# length, then the FIEMAP output will show blocks beyond EOF. That will cause +# trouble with the golden output, so skip this test if that will be the case. +_require_congruent_file_oplen $TEST_DIR $((5 * 1048576)) +_require_congruent_file_oplen $TEST_DIR $((7 * 1048576)) + # First test to make sure that truncating at i_size trims the preallocated bit # past i_size $XFS_IO_PROG -f -c "falloc -k 0 10M" -c "pwrite 0 5M" -c "truncate 5M"\ From patchwork Wed Oct 5 22:30:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12999643 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49C99C433F5 for ; Wed, 5 Oct 2022 22:30:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229704AbiJEWat (ORCPT ); Wed, 5 Oct 2022 18:30:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229710AbiJEWas (ORCPT ); Wed, 5 Oct 2022 18:30:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FB9A1EEC4; Wed, 5 Oct 2022 15:30:47 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E0885B81F7A; Wed, 5 Oct 2022 22:30:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D19BC433C1; Wed, 5 Oct 2022 22:30:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665009044; bh=fJPK+wpWaJL3FodWHs2P+KK7vPpUul/5CWtq5gJQX3k=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=IJJMse6S8XPlkS47Nh1P/nTRfkexFG6g2mLUMU19MYUAUiRzT1tp8lYXCvO9q6GBq aePLvdD3bDYujpMdD8tilIg0kYKVzWqrsLPadzArqOD90BzDxwzMVt2BdZUgN7xq2H f8Bce7dJQL+PYEbi72tZ5hvW9aUD+uEdwDve2tnnDOe6eijxZNbcM+ZUcdIRc1MxSx oWFUzzrah9AUySR6Nvui5gnwG8eTMEdYzg349yfIIpRJ4CKE4YjZnQl6oKfk8z9scx Fc8KlN05L+WDbHzNUA2ZAHd28qxIU1Jex2RQ6FAQ6oZxZFazV5cDoWWu2ymKoGZNWf Z7PWczHZ88KrQ== Subject: [PATCH 2/6] xfs/114: fix missing reflink requires From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Wed, 05 Oct 2022 15:30:44 -0700 Message-ID: <166500904418.886939.1997572513247565981.stgit@magnolia> In-Reply-To: <166500903290.886939.12532028548655386973.stgit@magnolia> References: <166500903290.886939.12532028548655386973.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 This test both requires cp --reflink and the scratch filesystem to support reflink. Add the missing _requires calls. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/xfs/114 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/xfs/114 b/tests/xfs/114 index 3aec814a5d..858dc3998e 100755 --- a/tests/xfs/114 +++ b/tests/xfs/114 @@ -18,6 +18,8 @@ _begin_fstest auto quick clone rmap collapse insert # real QA test starts here _supported_fs xfs _require_test_program "punch-alternating" +_require_cp_reflink +_require_scratch_reflink _require_xfs_scratch_rmapbt _require_xfs_io_command "falloc" _require_xfs_io_command "fcollapse" From patchwork Wed Oct 5 22:30:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12999644 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71EA9C433F5 for ; Wed, 5 Oct 2022 22:30:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229710AbiJEWaz (ORCPT ); Wed, 5 Oct 2022 18:30:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbiJEWay (ORCPT ); Wed, 5 Oct 2022 18:30:54 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D77A44684F; Wed, 5 Oct 2022 15:30:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8AE5DB81F77; Wed, 5 Oct 2022 22:30:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C0ACC433C1; Wed, 5 Oct 2022 22:30:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665009050; bh=dlCzwYSZL2S46PhtKd3S9gifQBXljx74ZQCC7k/4cgE=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=TTOzgwJWH6YaCYaSwQVdAKBX0A2exj/K1QTRat85cKLjPTe/B2o2Iwt965KNYJaWz Qg/CB+wOhGTztqb0lXS0XlKI84FgFCcktVccP4PgE0loff/csmgAeMJcm/rqLK+udl kVrwuFaTg7zUmxYajBtJfwzRjF/hopV2zSdXqdngc9ppeC36W9DeWThdJAPkB3kNye 2VeluK9BICBlhhsDVym+Fj8rpR1fxoPiDpNC4r2AEtOHD5Ny638r+bo3cnpjn0Oyl3 aUOLE/W+MsyeXO9CSsj/Q5bgZBWR5YJBW8RxOkgo1Oq/nZ1khhCAJcOizgvixtZjNK 62WWdN6rSb+JQ== Subject: [PATCH 3/6] xfs/229: do not _xfs_force_bdev on TEST_DIR From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Wed, 05 Oct 2022 15:30:49 -0700 Message-ID: <166500904980.886939.602653090532563176.stgit@magnolia> In-Reply-To: <166500903290.886939.12532028548655386973.stgit@magnolia> References: <166500903290.886939.12532028548655386973.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 ea15099b71, I observed that this test tries to test the behavior of the extent size hint on the data device. If the test runner set up MKFS_OPTIONS such that the filesystem gets created with a realtime section and rtinherit set on the root directory, then the preconditions of this test (creating files on the data section) is not satisfied and the results of this test are incorrect. The solution was to force all files created by this test to be assigned to the data section. Unfortunately, the correction that I made has side effects beyond this test -- by clearing rtinherit on $TEST_DIR, all tests that run after this one will create files on the data section, because the test filesystem persists for the duration of the entire test run. This leads to the wrong things being tested. Fix this new problem by clearing the rtinherit flag on $TDIR, which contains the files created by this test and is removed during cleanup, and leave a few comments celebrating our new discoveries. Fixes: ea15099b71 ("xfs: force file creation to the data device for certain layout tests") Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- common/xfs | 3 +++ tests/xfs/229 | 7 ++++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/common/xfs b/common/xfs index 170dd621a1..e1c15d3d04 100644 --- a/common/xfs +++ b/common/xfs @@ -201,6 +201,9 @@ _xfs_get_file_block_size() # For each directory, each file subsequently created will target the given # device for file data allocations. For each empty regular file, each # subsequent file data allocation will be on the given device. +# +# NOTE: If you call this on $TEST_DIR, you must reset the rtinherit flag state +# before the end of the test to avoid polluting subsequent tests. _xfs_force_bdev() { local device="$1" diff --git a/tests/xfs/229 b/tests/xfs/229 index 2221b9c49c..a58fd16bba 100755 --- a/tests/xfs/229 +++ b/tests/xfs/229 @@ -31,11 +31,16 @@ _require_fs_space $TEST_DIR 3200000 TDIR="${TEST_DIR}/t_holes" NFILES="10" EXTSIZE="256k" -_xfs_force_bdev data $TEST_DIR # Create the test directory mkdir ${TDIR} +# Per-directory extent size hints aren't particularly useful for files that +# are created on the realtime section. Force the test file to be created on +# the data directory. Do not change the rtinherit flag on $TEST_DIR because +# that will affect other tests. +_xfs_force_bdev data $TDIR + # Set the test directory extsize $XFS_IO_PROG -c "extsize ${EXTSIZE}" ${TDIR} From patchwork Wed Oct 5 22:30:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12999645 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 352D7C433FE for ; Wed, 5 Oct 2022 22:31:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229738AbiJEWa6 (ORCPT ); Wed, 5 Oct 2022 18:30:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbiJEWa5 (ORCPT ); Wed, 5 Oct 2022 18:30:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D268F58DDB; Wed, 5 Oct 2022 15:30:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 705726175C; Wed, 5 Oct 2022 22:30:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0DD3C433D6; Wed, 5 Oct 2022 22:30:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665009055; bh=QoF1P28beXgSkwGIF0IBtXluJjQz3WxasKXvLF005HM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=EYeWmw6ju8SE/ychXQgVIGisSBzY3Qj0ZEg8Oo3HEqTwLC9jWypLREh14b96asLdS heFUooIUYB1XIDFiEqwB5AcIKnE9QFztBSzkje4PUoAsnKuYdxjjYbbtEWY/yPDj4w d9FLbVKHyodjfoKyQjggezTJZ+hNARcjWsHyL7sRzqsmFVc1/9b5uMqVwKtwKFNySS bgtaZFtV8SRrIbfkpQR2/Db5VYD+oYfRCChT+erppTW0eLcjh/1Ys8nBlF09/sr4WO 3H3TawEMvHIJvxoxmRDKSznu4WidmNIDDg7P5TJaWArJTfWaojM3aPU8P1CK3IRgDo 2f6dqI4qf+ihg== Subject: [PATCH 4/6] xfs/128: try to force file allocation behavior From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Wed, 05 Oct 2022 15:30:55 -0700 Message-ID: <166500905541.886939.4232929527218167462.stgit@magnolia> In-Reply-To: <166500903290.886939.12532028548655386973.stgit@magnolia> References: <166500903290.886939.12532028548655386973.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 Over the years, I've noticed that this test occasionally fails when I've programmed the allocator to hand out the minimum amount of space with each allocation or if extent size hints are enabled: Reviewed-by: Zorro Lang --- /tmp/fstests/tests/xfs/128.out 2022-09-01 15:09:11.506679341 -0700 +++ /var/tmp/fstests/xfs/128.out.bad 2022-10-04 17:32:50.992000000 -0700 @@ -20,7 +21,9 @@ 56ed2f712c91e035adeeb26ed105a982 SCRATCH_MNT/test-128/file3 b81534f439aac5c34ce3ed60a03eba70 SCRATCH_MNT/test-128/file4 Check files free blocks after creating some reflink copies is in range free blocks after CoW some reflink copies is in range -free blocks after defragging all reflink copies is in range -free blocks after all tests is in range +free blocks after defragging all reflink copies has value of 8620027 +free blocks after defragging all reflink copies is NOT in range 8651819 .. 8652139 +free blocks after all tests has value of 8620027 +free blocks after all tests is NOT in range 8651867 .. 8652187 It turns out that under the right circumstances, the _pwrite_byte at the start of this test will end up allocating two extents to file1. This almost never happens when delalloc is enabled or when the extent size is large, and is more prone to happening if the extent size is > 1FSB but small, the allocator hands out small allocations, or if writeback shoots down pages in random order. When file1 gets more than 1 extent, problems start to happen. The free space accounting checks at the end of the test assume that file1 and file4 still share the same space at the end of the test. This definitely happens if file1 gets one extent (since fsr ignores single-extent files), but if there's more than 1, fsr will try to defragment it. If fsr succeeds in copying the file contents to a temp file with fewer extents than the source file, it will switch the contents, but unsharing the contents in the process. This cause the free space to be lower than expected, and the test fails. Resolve this situation by preallocating space beforehand to try to set up file1 with a single space extent. If the test fails and we got more than one extent, note that in the output. Signed-off-by: Darrick J. Wong --- tests/xfs/128 | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/tests/xfs/128 b/tests/xfs/128 index db5d9a60db..2d2975115e 100755 --- a/tests/xfs/128 +++ b/tests/xfs/128 @@ -34,7 +34,20 @@ margin=160 blksz=65536 real_blksz="$(_get_block_size $testdir)" blksz_factor=$((blksz / real_blksz)) + +# The expected free space numbers in this test require file1 and file4 to share +# the same blocks at the end of the test. Therefore, we need the allocator to +# give file1 a single extent at the start of the test so that fsr will not be +# tempted to "defragment" a multi-extent file1 or file4. Defragmenting really +# means rewriting the file, and if that succeeds on either file, we'll have +# unshared the space and there will be too little free space. Therefore, +# preallocate space to try to produce a single extent. +$XFS_IO_PROG -f -c "falloc 0 $((blks * blksz))" $testdir/file1 >> $seqres.full _pwrite_byte 0x61 0 $((blks * blksz)) $testdir/file1 >> $seqres.full +sync + +nextents=$($XFS_IO_PROG -c 'stat' $testdir/file1 | grep 'fsxattr.nextents' | awk '{print $3}') + _cp_reflink $testdir/file1 $testdir/file2 _cp_reflink $testdir/file2 $testdir/file3 _cp_reflink $testdir/file3 $testdir/file4 @@ -106,10 +119,23 @@ test $c14 = $c24 || echo "File4 changed by defrag" #echo $free_blocks0 $free_blocks1 $free_blocks2 $free_blocks3 -_within_tolerance "free blocks after creating some reflink copies" $free_blocks1 $((free_blocks0 - (blks * blksz_factor) )) $margin -v -_within_tolerance "free blocks after CoW some reflink copies" $free_blocks2 $((free_blocks1 - 2)) $margin -v -_within_tolerance "free blocks after defragging all reflink copies" $free_blocks3 $((free_blocks2 - (blks * 2 * blksz_factor))) $margin -v -_within_tolerance "free blocks after all tests" $free_blocks3 $((free_blocks0 - (blks * 3 * blksz_factor))) $margin -v +freesp_bad=0 + +_within_tolerance "free blocks after creating some reflink copies" \ + $free_blocks1 $((free_blocks0 - (blks * blksz_factor) )) $margin -v || freesp_bad=1 + +_within_tolerance "free blocks after CoW some reflink copies" \ + $free_blocks2 $((free_blocks1 - 2)) $margin -v || freesp_bad=1 + +_within_tolerance "free blocks after defragging all reflink copies" \ + $free_blocks3 $((free_blocks2 - (blks * 2 * blksz_factor))) $margin -v || freesp_bad=1 + +_within_tolerance "free blocks after all tests" \ + $free_blocks3 $((free_blocks0 - (blks * 3 * blksz_factor))) $margin -v || freesp_bad=1 + +if [ $freesp_bad -ne 0 ] && [ $nextents -gt 0 ]; then + echo "free space checks probably failed because file1 nextents was $nextents" +fi # success, all done status=0 From patchwork Wed Oct 5 22:31:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12999646 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0575EC433FE for ; Wed, 5 Oct 2022 22:31:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229620AbiJEWbE (ORCPT ); Wed, 5 Oct 2022 18:31:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbiJEWbD (ORCPT ); Wed, 5 Oct 2022 18:31:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BD2083F28; Wed, 5 Oct 2022 15:31:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1970C617BF; Wed, 5 Oct 2022 22:31:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7578AC433C1; Wed, 5 Oct 2022 22:31:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665009061; bh=5xuLgnuncb/cE8rZF9FKplElkdPJprnPdd8Ql+Kx0RU=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=WQITEWGEjWNLNi4CKJi/LV8qGKRrUqUpOw6REGvMQX0uO4UiiWChMwMZps0nuUV0L x7rMsTUMOqwEpGxaoM9i7emKigztVakLDuCmSTd75pps3G4GKLoVicro+2WMIPSymN 46AZCAaVAug3eDMl1z5+axfEXX9Gry30hoOPpGLwKoXEDQNt5PuoTxi5xwPAMKledX rYF+KeMQNJPrd+SC6cOJ4Tgo4VQkZssl36qcEQbAHZwi1L5BM8lXdOvWFvQdJe4O7X 1awc1sfjCjrXDV0D7Zd7dcQgni3nDfYGKjPMb/shnGBZBWlorpHOF34QJtq61X+zTV Y9U6Q/SEBeHiA== Subject: [PATCH 5/6] common/populate: don't metadump xfs filesystems twice From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Wed, 05 Oct 2022 15:31:01 -0700 Message-ID: <166500906102.886939.861772249521756043.stgit@magnolia> In-Reply-To: <166500903290.886939.12532028548655386973.stgit@magnolia> References: <166500903290.886939.12532028548655386973.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 Due to some braino on my part, _scratch_populate_cached will metadump the filesystem twice -- once with compression disabled, and again with it enabled, maybe. Get rid of the first metadump. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- common/populate | 1 - 1 file changed, 1 deletion(-) diff --git a/common/populate b/common/populate index 9739ac99e0..4eee7e8c66 100644 --- a/common/populate +++ b/common/populate @@ -890,7 +890,6 @@ _scratch_populate_cached() { "xfs") _scratch_xfs_populate $@ _scratch_xfs_populate_check - _scratch_xfs_metadump "${POPULATE_METADUMP}" local logdev= [ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \ From patchwork Wed Oct 5 22:31:06 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12999647 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83D8FC433FE for ; Wed, 5 Oct 2022 22:31:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229496AbiJEWbJ (ORCPT ); Wed, 5 Oct 2022 18:31:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229687AbiJEWbI (ORCPT ); Wed, 5 Oct 2022 18:31:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 129A183F28; Wed, 5 Oct 2022 15:31:08 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A519E617E5; Wed, 5 Oct 2022 22:31:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A5DBC433B5; Wed, 5 Oct 2022 22:31:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665009067; bh=tN+pI5TIJ/FHJZ7DtmUX0JuK9o5Pd0pwl8Ib3nY9hDw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=dPbaSjqXM/O4kfZVqZWnV61ixCyl4udJimzGKIqf9w1CQ+FMUc9LZXRUjXlaBo91Q MjZrH/lZYQ7Bog3Bl/aiOJZs/KtUqXxyDRERDvjGPlaYgh0OLNE5gvRz5uGsu6EyjD Eqd8rMgTm3noJMv9/WjH9unM3Gra7xNhtHfGiwS5aB8Z0bf4kNjZH4DQZoWg0wKsg0 UBBZBFQyQ9iF0KC9Q5gKIecjSFYfhcIlIpyHSG3RyhWShxkN0IXQWDpxClt2NlYanr /QDe9jlUrAcWJnQv7H7Te/95CX/CEwcA72zsNHWJttvahHhM92a0dIcPEJiG1OnZcr Nw7QSK9o3VAUQ== Subject: [PATCH 6/6] common/populate: fix _xfs_metadump usage in _scratch_populate_cached From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Wed, 05 Oct 2022 15:31:06 -0700 Message-ID: <166500906664.886939.1596674456976768238.stgit@magnolia> In-Reply-To: <166500903290.886939.12532028548655386973.stgit@magnolia> References: <166500903290.886939.12532028548655386973.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 _xfs_metadump requires that the caller pass in "none" for the log device if it doesn't have a log device, so fix this call site. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- common/populate | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/populate b/common/populate index 4eee7e8c66..cfdaf766f0 100644 --- a/common/populate +++ b/common/populate @@ -891,7 +891,7 @@ _scratch_populate_cached() { _scratch_xfs_populate $@ _scratch_xfs_populate_check - local logdev= + local logdev=none [ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \ logdev=$SCRATCH_LOGDEV