From patchwork Wed Mar 16 03:30:09 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: 12782175 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 D2D02C433F5 for ; Wed, 16 Mar 2022 03:30:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353455AbiCPDbZ (ORCPT ); Tue, 15 Mar 2022 23:31:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353450AbiCPDbZ (ORCPT ); Tue, 15 Mar 2022 23:31:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 414053981F; Tue, 15 Mar 2022 20:30:12 -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 E7F4FB81883; Wed, 16 Mar 2022 03:30:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96F3AC340E8; Wed, 16 Mar 2022 03:30:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647401409; bh=oKYIh0hVq+dJHf9GEEF/9uewAwfU3ZAVXop7uqNYhR4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=S8usV3bXLEt5S6OQf20REWvEUPtyHBzE7zo7PxTHBfwqsOxt//WufNP8Y3pjfN3FS e1LItVVzxpwZt75d4//cotV05M6iu3qiKq7Bm4GrPKWgysKvZguSSlIEwYB2gKMqaF 1s9O/mftkDgQ6s/xRMkYKvtbHLLGHF1PaQKbpCFC7k81h6P4hR6obXvvUnI2Hqt+9u bb40rdX/cep2ie61cykDc37UvCHK9HP27XIgWBfnHN9lvYPiV51uUxy3DKDdJGRlrQ hX8SkuVaKAwBUmtuWTRCXkP6m7B4byzLkXPznFVUl9cZp4I3Kt4fg0/z4qJ9oWx1uN 6mCRXyHTp1RYg== Subject: [PATCH 1/4] generic/459: ensure that the lvm devices have been created 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, 15 Mar 2022 20:30:09 -0700 Message-ID: <164740140920.3371628.4554997239924071993.stgit@magnolia> In-Reply-To: <164740140348.3371628.12967562090320741592.stgit@magnolia> References: <164740140348.3371628.12967562090320741592.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 Once in a /very/ long while this test fails because _mkfs_dev can't find the LVM thinp volume after it's been created. Since the "solution" du jour seems to be to sprinkle udevadm settle calls everywhere, do that here in the hopes that will fix it. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/generic/459 | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/generic/459 b/tests/generic/459 index cda19e6e..57d58e55 100755 --- a/tests/generic/459 +++ b/tests/generic/459 @@ -70,6 +70,7 @@ $LVM_PROG lvcreate --virtualsize $virtsize \ -T $vgname/$poolname \ -n $lvname >>$seqres.full 2>&1 +$UDEV_SETTLE_PROG &>/dev/null _mkfs_dev /dev/mapper/$vgname-$lvname >>$seqres.full 2>&1 # Running the test over the original volume doesn't reproduce the problem From patchwork Wed Mar 16 03:30:14 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: 12782176 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 7BD61C433F5 for ; Wed, 16 Mar 2022 03:30:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353450AbiCPDb3 (ORCPT ); Tue, 15 Mar 2022 23:31:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353459AbiCPDb3 (ORCPT ); Tue, 15 Mar 2022 23:31:29 -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 2D2995EDD6; Tue, 15 Mar 2022 20:30:16 -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 BD03E615F3; Wed, 16 Mar 2022 03:30:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2ACFBC340E8; Wed, 16 Mar 2022 03:30:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647401415; bh=OLz1A+9iUlvgF7/IP6e6LLOIuhUOIh0OWEXptIGid1g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=gt9Mwx2uAfFXrpL0oGQJ+iaEyeOY2jrD0o20vK0ByLXRst5m3WQys1SELbCmZ7vGa zzw4nhbVBwH10n6ojI6ANAFge9y/hcSKqmzldlMm0vbq0C3DCsx+CQWatMeRV/l212 pU9471iMsQMzj78uAYG9ce3oBvM9Rs5iBhgxH/2FSJIXt/E3m+J1FMSfV36hfP3Jh+ d6EZxQUTXKV7mxSVGclG/BPHM1r2F92h3eLOliCkLBW9fdp2edczkc5/XQer+VExpq hbqMCUHYxzPoHWKheasOdocQ6bcEtzcmipxGpgvf8vZvmO2joeFLoEOk1EKwOVPAel towUyp2jM5lyQ== Subject: [PATCH 2/4] common/xfs: fix broken code in _check_xfs_filesystem 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, 15 Mar 2022 20:30:14 -0700 Message-ID: <164740141477.3371628.6804259397500636490.stgit@magnolia> In-Reply-To: <164740140348.3371628.12967562090320741592.stgit@magnolia> References: <164740140348.3371628.12967562090320741592.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 Fix some problems with undefined variables in the scrub control code. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- common/xfs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/common/xfs b/common/xfs index 053b6189..ac1d021e 100644 --- a/common/xfs +++ b/common/xfs @@ -568,12 +568,12 @@ _check_xfs_filesystem() # before executing a scrub operation. $XFS_IO_PROG -c syncfs $mntpt >> $seqres.full 2>&1 - "$XFS_SCRUB_PROG" $scrubflag -v -d -n $mntpt > $tmp.scrub 2>&1 + "$XFS_SCRUB_PROG" -v -d -n $mntpt > $tmp.scrub 2>&1 if [ $? -ne 0 ]; then _log_err "_check_xfs_filesystem: filesystem on $device failed scrub" - echo "*** xfs_scrub $scrubflag -v -d -n output ***" >> $seqres.full + echo "*** xfs_scrub -v -d -n output ***" >> $seqres.full cat $tmp.scrub >> $seqres.full - echo "*** end xfs_scrub output" >> $serqres.full + echo "*** end xfs_scrub output" >> $seqres.full ok=0 fi rm -f $tmp.scrub From patchwork Wed Mar 16 03:30:20 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: 12782177 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 50BDDC433F5 for ; Wed, 16 Mar 2022 03:30:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239664AbiCPDbj (ORCPT ); Tue, 15 Mar 2022 23:31:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353461AbiCPDbh (ORCPT ); Tue, 15 Mar 2022 23:31:37 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AD0C5EDD6; Tue, 15 Mar 2022 20:30:23 -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 19C8CB81A07; Wed, 16 Mar 2022 03:30:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD9DFC340E8; Wed, 16 Mar 2022 03:30:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647401420; bh=JKKe2NS4fpIiMOxt3ym4v5T1bubiUMQB/Tx8c8lg0i8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=W7TlEp7QvJGzd0QhAJrjfMAXLKq9OezxJ1mnTZr9z1eqyWy34n95KkRqeJi6QUC4x erLHOROYcwjVN6H6ehNfs6YCP2Sl7rjP1ChvQQ3uaWuMDMCg4IOIjfkhveivVak40H +8ee4F6Nbllz2wavLDPrvtr2/XANZmMczm7onszmp/oqiYXiyFZBlZkBg5/EhhmtxQ XfvteCUTMkSCz8HzwZ29MMZ88AFYp6Ig6N7ULiyufZna4sQ31SOsSMKtOfje1FJIOy cSjC1uYtPjVpp3d9VCt6lJ7sk2h604JNVGAQkuwnKcSXuDvY26keKobKgtFICRiZY9 MlUhQ9tYDePeQ== Subject: [PATCH 3/4] xfs/420: fix occasional test failures due to pagecache readahead From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com Cc: Matthew Wilcox , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Tue, 15 Mar 2022 20:30:20 -0700 Message-ID: <164740142033.3371628.11850774504699213977.stgit@magnolia> In-Reply-To: <164740140348.3371628.12967562090320741592.stgit@magnolia> References: <164740140348.3371628.12967562090320741592.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 Every now and then, this test fails with this golden output: --- xfs/420.out +++ xfs/420.out.bad @@ -29,7 +29,7 @@ Whence Result DATA 0 HOLE 131072 -DATA 196608 +DATA 192512 HOLE 262144 Compare files c2803804acc9936eef8aab42c119bfac SCRATCH_MNT/test-420/file1 Curiously, the file checksums always match, and it's not *forbidden* for the page cache to have a page backing an unwritten extent that hasn't been written. The condition that this test cares about is that block 3 (192k-256k) are reported by SEEK_DATA as data even if the data fork has a hole and the COW fork has an unwritten extent. Matthew Wilcox thinks this is a side effect of readahead. To fix this occasional false failure, call SEEK_DATA and SEEK_HOLE only on the offsets that we care about. Suggested-by: Matthew Wilcox Signed-off-by: Darrick J. Wong --- tests/xfs/420 | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/tests/xfs/420 b/tests/xfs/420 index 12b17588..d38772c9 100755 --- a/tests/xfs/420 +++ b/tests/xfs/420 @@ -50,6 +50,24 @@ _scratch_mount >> $seqres.full 2>&1 testdir=$SCRATCH_MNT/test-$seq mkdir $testdir +# pagecache readahead can sometimes cause extra pages to be inserted into the +# file mapping where we have an unwritten extent in the COW fork. Call lseek +# on each $blksz offset that interests us (as opposed to the whole file) so +# that these extra pages are not disclosed. +# +# The important thing we're testing is that SEEK_DATA reports block 3 as data +# when the COW fork has an unwritten mapping and the data fork has a hole. +exercise_lseek() { + echo "Seek holes and data in file1" + $XFS_IO_PROG -c "seek -d 0" $testdir/file1 + $XFS_IO_PROG -c "seek -h $((2 * blksz))" $testdir/file1 | sed -e '/Whence/d' + echo "Seek holes and data in file2" + $XFS_IO_PROG -c "seek -d 0" $testdir/file2 + $XFS_IO_PROG -c "seek -h $((2 * blksz))" $testdir/file2 | sed -e '/Whence/d' + $XFS_IO_PROG -c "seek -d $((3 * blksz))" $testdir/file2 | sed -e '/Whence/d' + $XFS_IO_PROG -c "seek -h $((4 * blksz))" $testdir/file2 | sed -e '/Whence/d' +} + blksz=65536 nr=8 filesize=$((blksz * nr)) @@ -83,10 +101,7 @@ $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file1 >> $seqres.full 2>&1 $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file2 >> $seqres.full 2>&1 $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file3 >> $seqres.full 2>&1 -echo "Seek holes and data in file1" -$XFS_IO_PROG -c "seek -a -r 0" $testdir/file1 -echo "Seek holes and data in file2" -$XFS_IO_PROG -c "seek -a -r 0" $testdir/file2 +exercise_lseek echo "Compare files" md5sum $testdir/file1 | _filter_scratch @@ -102,10 +117,7 @@ $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file1 >> $seqres.full 2>&1 $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file2 >> $seqres.full 2>&1 $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file3 >> $seqres.full 2>&1 -echo "Seek holes and data in file1" -$XFS_IO_PROG -c "seek -a -r 0" $testdir/file1 -echo "Seek holes and data in file2" -$XFS_IO_PROG -c "seek -a -r 0" $testdir/file2 +exercise_lseek echo "Compare files" md5sum $testdir/file1 | _filter_scratch @@ -121,10 +133,7 @@ $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file1 >> $seqres.full 2>&1 $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file2 >> $seqres.full 2>&1 $XFS_IO_PROG -c "bmap -ev" -c "bmap -cv" $testdir/file3 >> $seqres.full 2>&1 -echo "Seek holes and data in file1" -$XFS_IO_PROG -c "seek -a -r 0" $testdir/file1 -echo "Seek holes and data in file2" -$XFS_IO_PROG -c "seek -a -r 0" $testdir/file2 +exercise_lseek echo "Compare files" md5sum $testdir/file1 | _filter_scratch From patchwork Wed Mar 16 03:30:25 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: 12782178 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 B26D8C433FE for ; Wed, 16 Mar 2022 03:30:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349228AbiCPDbk (ORCPT ); Tue, 15 Mar 2022 23:31:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353461AbiCPDbk (ORCPT ); Tue, 15 Mar 2022 23:31:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 672863981F; Tue, 15 Mar 2022 20:30:27 -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 037F161716; Wed, 16 Mar 2022 03:30:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CE99C340E8; Wed, 16 Mar 2022 03:30:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647401426; bh=euXMmFFqv5U92GMGhH0sggzumUK8fKZB3HfYE667j3U=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=YkQYD2nPBXVqWFQEvxuFg9nn7Gur7tEGJh5XNXHh8LtsYbqFkB45+LR5mlMYRUl6y YqljX+rwR3lglYtYUtqk5pz6B/8JZlV/uhFp5/Z5V6myZ/6MWEiVaKSUEGaepsl/0G dBfteia36yFYRS0jZIOsFfEWABc4YwHFHLSHZEMie3rgscBr1z5pxbLp2KgPLhH0Tk A1A1moiGS/E5B1H+7Yd4rwBsXcnHLZUWIrbz85KiK/D2qCJtNFUFfKpUFMXj8FbWW5 T6dJGYFW2tIwJZwQ/IcckSfMnAIIVECr7ZFG1Gt8xcvP4JlhMULr44R4TjdSDm2OVI L0f9oKWKMmFxw== Subject: [PATCH 4/4] generic/673: fix golden output to reflect vfs setgid behavior 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, 15 Mar 2022 20:30:25 -0700 Message-ID: <164740142591.3371628.12793589713189041823.stgit@magnolia> In-Reply-To: <164740140348.3371628.12967562090320741592.stgit@magnolia> References: <164740140348.3371628.12967562090320741592.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 Filipe Manana pointed out[1] that the setgid dropping behavior encoded in this generic test is based on some outdated XFS code, and not based on what the VFS inode attribute change functions actually do. Now that we're working on fixing that, we should update the golden output to reflect what all filesystems are supposed to be doing. [1] https://lore.kernel.org/linux-xfs/CAL3q7H47iNQ=Wmk83WcGB-KBJVOEtR9+qGczzCeXJ9Y2KCV25Q@mail.gmail.com/ Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/generic/673.out | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/generic/673.out b/tests/generic/673.out index 8df672d6..4d18bca2 100644 --- a/tests/generic/673.out +++ b/tests/generic/673.out @@ -3,7 +3,7 @@ Test 1 - qa_user, non-exec file 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/a 6666 -rwSrwSrw- SCRATCH_MNT/a 3784de23efab7a2074c9ec66901e39e5 SCRATCH_MNT/a -2666 -rw-rwSrw- SCRATCH_MNT/a +666 -rw-rw-rw- SCRATCH_MNT/a Test 2 - qa_user, group-exec file 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/a @@ -15,7 +15,7 @@ Test 3 - qa_user, user-exec file 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/a 6766 -rwsrwSrw- SCRATCH_MNT/a 3784de23efab7a2074c9ec66901e39e5 SCRATCH_MNT/a -2766 -rwxrwSrw- SCRATCH_MNT/a +766 -rwxrw-rw- SCRATCH_MNT/a Test 4 - qa_user, all-exec file 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/a From patchwork Wed Mar 16 22:12:32 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: 12783231 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 88FA6C433F5 for ; Wed, 16 Mar 2022 22:12:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242365AbiCPWN4 (ORCPT ); Wed, 16 Mar 2022 18:13:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232357AbiCPWN4 (ORCPT ); Wed, 16 Mar 2022 18:13:56 -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 DE07FE7; Wed, 16 Mar 2022 15:12:33 -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 65CE2615C7; Wed, 16 Mar 2022 22:12:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAD90C340EC; Wed, 16 Mar 2022 22:12:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647468752; bh=2kEep88jHjTUvaI3I8B0kb+rbxmj2CH2dOUf5Qlb58s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t+2SfS/mBb14fkAGiMbVu/31NsWCVzNhwpzGZtJ0O9gVlOSANqg9AjiMG8cVgY6ey efkMr23RJpmWGCma7rTXKVx3nyRyHOWfuYRWJHU0KjG5+49zwTF5vGuenZfXiCbfK8 zcHkpIPAtdOLEKGkF9OlyX85cWw1SvmxUz95qmXOjglCkxZ+bptkCKI9NvjJ6SrRv7 tJ7FX/8JNJRyfDwb5iaaVvVixnWvnz16rGzIpJ1pB7U9JLt1SZ2pNaHRnUYTEnqMJ3 FRFD3G5nm5u4rtpG7uB/oTSxwDeKp/hyPHlUaWlIBExYyQ2RAewjRTU0sMLRNGGdJ9 5jBjpbYwn3Zxw== Date: Wed, 16 Mar 2022 15:12:32 -0700 From: "Darrick J. Wong" To: guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Subject: [PATCH 5/4] xfs/076: only create files on the data device Message-ID: <20220316221232.GE8200@magnolia> References: <164740140348.3371628.12967562090320741592.stgit@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <164740140348.3371628.12967562090320741592.stgit@magnolia> Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong This test checks that filesystems with sparse inode support can continue to allocate inodes when free space gets fragmented. Inodes only exist on the data device, so we need to ensure that realtime is not enabled on the filesystem so that the rt metadata doesn't mess with the inode usage percentage and cause a test failure. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/xfs/076 | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/tests/xfs/076 b/tests/xfs/076 index eac7410e..8eef1367 100755 --- a/tests/xfs/076 +++ b/tests/xfs/076 @@ -55,12 +55,21 @@ _alloc_inodes() # real QA test starts here -_require_scratch +if [ -n "$SCRATCH_RTDEV" ]; then + # ./check won't know we unset SCRATCH_RTDEV + _require_scratch_nocheck +else + _require_scratch +fi _require_xfs_io_command "falloc" _require_xfs_io_command "fpunch" _require_xfs_sparse_inodes -_scratch_mkfs "-d size=50m -m crc=1 -i sparse" | +# Disable the scratch rt device to avoid test failures relating to the rt +# bitmap consuming all the free space in our small data device. +unset SCRATCH_RTDEV + +_scratch_mkfs "-d size=50m -m crc=1 -i sparse" | tee -a $seqres.full | _filter_mkfs > /dev/null 2> $tmp.mkfs . $tmp.mkfs # for isize From patchwork Wed Mar 16 22:13:26 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: 12783232 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 9DC2EC433EF for ; Wed, 16 Mar 2022 22:13:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353389AbiCPWOq (ORCPT ); Wed, 16 Mar 2022 18:14:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351826AbiCPWOp (ORCPT ); Wed, 16 Mar 2022 18:14:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C0BCBC9; Wed, 16 Mar 2022 15:13:29 -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 E257CB81D67; Wed, 16 Mar 2022 22:13:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8978C340EE; Wed, 16 Mar 2022 22:13:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647468806; bh=NMZsFOI5weCHLRDmXOJCw8qnrDlsD1WYwo8WBklkJaw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cLO9BmxjpkEL86tBw13UxRx/SuDgwer3d8Sd/sqau6f0+L0082ccgCulTHW314Cfb pgmBnlT37YWgumGxntnOhiNCVxLUc6K2JncuMuDxzWXpcNB36l45jZ0T+p99Ku1L5b COLHpMeBbGdplQDliQ1bexj1LlpUbYo/PMGC0RtqTOQJVGd7V1FqSP3bklSkcT6W3O c0KtiuLOBzJlUTCLIX+tHCkPnM1vc6Up8O7ilcKTjmMCzzkjWTlGfIImMmMVyYfS8G +mTSuwe+YudY4AwRZx+L9toRfxmbzwjQwAEipyTKLTgJped/PBhu7Rq0wDSSd6beyF 65gfz83e8HaMQ== Date: Wed, 16 Mar 2022 15:13:26 -0700 From: "Darrick J. Wong" To: guaneryu@gmail.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Subject: [PATCH 6/4] xfs/17[035]: fix intermittent failures when filesystem metadata gets large Message-ID: <20220316221326.GF8200@magnolia> References: <164740140348.3371628.12967562090320741592.stgit@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <164740140348.3371628.12967562090320741592.stgit@magnolia> Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong These tests check that the filestreams allocator never shares an AG across multiple streams when there's plenty of space in the filesystem. Recent increases in metadata overhead for newer features (e.g. bigger logs due to reflink) can throw this off, so add another AG to the formatted filesystem to encourage it to avoid the AG with the log. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- common/filestreams | 2 +- tests/xfs/170 | 16 +++++++++++----- tests/xfs/170.out | 8 ++++---- tests/xfs/171 | 16 ++++++++++++---- tests/xfs/171.out | 8 ++++---- tests/xfs/173 | 16 ++++++++++++---- tests/xfs/173.out | 8 ++++---- 7 files changed, 48 insertions(+), 26 deletions(-) diff --git a/common/filestreams b/common/filestreams index 8165effe..62acb47c 100644 --- a/common/filestreams +++ b/common/filestreams @@ -80,7 +80,7 @@ _check_for_dupes() _test_streams() { - echo "# testing $* ...." + echo "# testing $* ...." | tee -a $seqres.full local agcount="$1" local agsize="$2" # in MB local stream_count="$3" diff --git a/tests/xfs/170 b/tests/xfs/170 index 5e622d24..b9ead341 100755 --- a/tests/xfs/170 +++ b/tests/xfs/170 @@ -25,11 +25,17 @@ _check_filestreams_support || _notrun "filestreams not available" # test small stream, multiple I/O per file, 30s timeout _set_stream_timeout_centisecs 3000 -# test streams does a mkfs and mount -_test_streams 8 22 4 8 3 0 0 -_test_streams 8 22 4 8 3 1 0 -_test_streams 8 22 4 8 3 0 1 -_test_streams 8 22 4 8 3 1 1 +# This test checks that the filestreams allocator never allocates space in any +# given AG into more than one stream when there's plenty of space on the +# filesystem. Newer feature sets (e.g. reflink) have increased the size of +# the log for small filesystems, so we make sure there's one more AG than +# filestreams to encourage the allocator to skip whichever AG owns the log. +# +# Exercise 9x 22MB AGs, 4 filestreams, 8 files per stream, and 3MB per file. +_test_streams 9 22 4 8 3 0 0 +_test_streams 9 22 4 8 3 1 0 +_test_streams 9 22 4 8 3 0 1 +_test_streams 9 22 4 8 3 1 1 status=0 exit diff --git a/tests/xfs/170.out b/tests/xfs/170.out index e71515e9..16dcb795 100644 --- a/tests/xfs/170.out +++ b/tests/xfs/170.out @@ -1,20 +1,20 @@ QA output created by 170 -# testing 8 22 4 8 3 0 0 .... +# testing 9 22 4 8 3 0 0 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 8 22 4 8 3 1 0 .... +# testing 9 22 4 8 3 1 0 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 8 22 4 8 3 0 1 .... +# testing 9 22 4 8 3 0 1 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 8 22 4 8 3 1 1 .... +# testing 9 22 4 8 3 1 1 .... # streaming # sync AGs... # checking stream AGs... diff --git a/tests/xfs/171 b/tests/xfs/171 index 4412fe2f..f93b6011 100755 --- a/tests/xfs/171 +++ b/tests/xfs/171 @@ -29,10 +29,18 @@ _check_filestreams_support || _notrun "filestreams not available" # 100 = 78.1% full, should reliably succeed _set_stream_timeout_centisecs 12000 -_test_streams 64 16 8 100 1 1 0 -_test_streams 64 16 8 100 1 1 1 -_test_streams 64 16 8 100 1 0 0 -_test_streams 64 16 8 100 1 0 1 +# This test tries to get close to the exact point at which the filestreams +# allocator will start to allocate space from some AG into more than one +# stream. Newer feature sets (e.g. reflink) have increased the size of the log +# for small filesystems, so we make sure there's one more AG than filestreams +# to encourage the allocator to skip whichever AG owns the log. +# +# This test exercises 64x 16MB AGs, 8 filestreams, 100 files per stream, and +# 1MB per file. +_test_streams 65 16 8 100 1 1 0 +_test_streams 65 16 8 100 1 1 1 +_test_streams 65 16 8 100 1 0 0 +_test_streams 65 16 8 100 1 0 1 status=0 exit diff --git a/tests/xfs/171.out b/tests/xfs/171.out index 89407cb2..73f73c90 100644 --- a/tests/xfs/171.out +++ b/tests/xfs/171.out @@ -1,20 +1,20 @@ QA output created by 171 -# testing 64 16 8 100 1 1 0 .... +# testing 65 16 8 100 1 1 0 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 64 16 8 100 1 1 1 .... +# testing 65 16 8 100 1 1 1 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 64 16 8 100 1 0 0 .... +# testing 65 16 8 100 1 0 0 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 64 16 8 100 1 0 1 .... +# testing 65 16 8 100 1 0 1 .... # streaming # sync AGs... # checking stream AGs... diff --git a/tests/xfs/173 b/tests/xfs/173 index bce6ac51..6b18d919 100755 --- a/tests/xfs/173 +++ b/tests/xfs/173 @@ -26,10 +26,18 @@ _check_filestreams_support || _notrun "filestreams not available" # be less than or equal to half the AG count so we don't run out of AGs. _set_stream_timeout_centisecs 12000 -_test_streams 64 16 33 8 2 1 1 fail -_test_streams 64 16 32 8 2 0 1 -_test_streams 64 16 33 8 2 0 0 fail -_test_streams 64 16 32 8 2 1 0 +# This test checks the exact point at which the filestreams allocator will +# start to allocate space from some AG into more than one stream. Newer +# feature sets (e.g. reflink) have increased the size of the log for small +# filesystems, so we make sure there's one more AG than filestreams to +# encourage the allocator to skip whichever AG owns the log. +# +# Exercise 65x 16MB AGs, 32/33 filestreams, 8 files per stream, and 2MB per +# file. +_test_streams 65 16 34 8 2 1 1 fail +_test_streams 65 16 32 8 2 0 1 +_test_streams 65 16 34 8 2 0 0 fail +_test_streams 65 16 32 8 2 1 0 status=0 exit diff --git a/tests/xfs/173.out b/tests/xfs/173.out index 21493057..705c352a 100644 --- a/tests/xfs/173.out +++ b/tests/xfs/173.out @@ -1,20 +1,20 @@ QA output created by 173 -# testing 64 16 33 8 2 1 1 fail .... +# testing 65 16 34 8 2 1 1 fail .... # streaming # sync AGs... # checking stream AGs... + expected failure, matching AGs -# testing 64 16 32 8 2 0 1 .... +# testing 65 16 32 8 2 0 1 .... # streaming # sync AGs... # checking stream AGs... + passed, streams are in seperate AGs -# testing 64 16 33 8 2 0 0 fail .... +# testing 65 16 34 8 2 0 0 fail .... # streaming # sync AGs... # checking stream AGs... + expected failure, matching AGs -# testing 64 16 32 8 2 1 0 .... +# testing 65 16 32 8 2 1 0 .... # streaming # sync AGs... # checking stream AGs...