From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: kernel test robot <oliver.sang@intel.com>,
Josef Bacik <josef@toxicpanda.com>
Cc: David Sterba <dsterba@suse.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
lkp@lists.01.org, lkp@intel.com, linux-btrfs@vger.kernel.org
Subject: Re: [btrfs] ccb0edc68b: xfstests.btrfs.179.fail
Date: Thu, 26 Nov 2020 19:09:31 +0800 [thread overview]
Message-ID: <e8402d80-0255-ff89-f6a0-d0fc8b4ad827@gmx.com> (raw)
In-Reply-To: <20201126085618.GA14546@xsang-OptiPlex-9020>
[-- Attachment #1.1: Type: text/plain, Size: 5446 bytes --]
On 2020/11/26 下午4:56, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: ccb0edc68b690d0a62e9377ab509eb2f7cb610d3 ("btrfs: stop running all delayed refs during snapshot")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
>
> in testcase: xfstests
> version: xfstests-x86_64-d41dcbd-1_20201116
> with following parameters:
>
> disk: 6HDD
> fs: btrfs
> test: btrfs-group-03
> ucode: 0x28
>
> test-description: xfstests is a regression test suite for xfs and other files ystems.
> test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
>
> on test machine: 8 threads Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 8G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <oliver.sang@intel.com>
>
> 2020-11-25 22:50:45 export TEST_DIR=/fs/sdb1
> 2020-11-25 22:50:45 export TEST_DEV=/dev/sdb1
> 2020-11-25 22:50:45 export FSTYP=btrfs
> 2020-11-25 22:50:45 export SCRATCH_MNT=/fs/scratch
> 2020-11-25 22:50:45 mkdir /fs/scratch -p
> 2020-11-25 22:50:45 export SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6"
> 2020-11-25 22:50:45 sed "s:^:btrfs/:" //lkp/benchmarks/xfstests/tests/btrfs-group-03
> 2020-11-25 22:50:45 ./check btrfs/150 btrfs/151 btrfs/152 btrfs/153 btrfs/155 btrfs/156 btrfs/157 btrfs/158 btrfs/159 btrfs/160 btrfs/161 btrfs/162 btrfs/163 btrfs/164 btrfs/165 btrfs/166 btrfs/167 btrfs/168 btrfs/169 btrfs/170 btrfs/171 btrfs/172 btrfs/173 btrfs/174 btrfs/175 btrfs/176 btrfs/177 btrfs/178 btrfs/179 btrfs/180 btrfs/181 btrfs/182 btrfs/183 btrfs/184 btrfs/185 btrfs/186 btrfs/187 btrfs/188 btrfs/189 btrfs/190 btrfs/191 btrfs/192 btrfs/193 btrfs/194 btrfs/195 btrfs/196 btrfs/197 btrfs/198 btrfs/199
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 lkp-hsw-d01 5.10.0-rc5-00155-gccb0edc68b69 #1 SMP Thu Nov 26 04:34:38 CST 2020
> MKFS_OPTIONS -- /dev/sdb2
> MOUNT_OPTIONS -- /dev/sdb2 /fs/scratch
>
> btrfs/150 1s
> btrfs/151 2s
> btrfs/152 6s
> btrfs/153 3s
> btrfs/155 1s
> btrfs/156 [not run] FITRIM not supported on /fs/scratch
> btrfs/157 2s
> btrfs/158 2s
> btrfs/159 11s
> btrfs/160 2s
> btrfs/161 1s
> btrfs/162 3s
> btrfs/163 - output mismatch (see /lkp/benchmarks/xfstests/results//btrfs/163.out.bad)
> --- tests/btrfs/163.out 2020-11-16 06:09:57.000000000 +0000
> +++ /lkp/benchmarks/xfstests/results//btrfs/163.out.bad 2020-11-25 22:51:22.553853766 +0000
> @@ -1,8 +1,10 @@
> QA output created by 163
> +./common/btrfs: line 405: _require_loadable_fs_module: command not found
> -- golden --
> 0000000 abab abab abab abab abab abab abab abab
> *
> 20000000
> +./common/btrfs: line 412: _reload_fs_module: command not found
> ...
> (Run 'diff -u /lkp/benchmarks/xfstests/tests/btrfs/163.out /lkp/benchmarks/xfstests/results//btrfs/163.out.bad' to see the entire diff)
> btrfs/164 [not run] Require module btrfs to be unloadable
> btrfs/165 1s
> btrfs/166 1s
> btrfs/167 2s
> btrfs/168 1s
> btrfs/169 2s
> btrfs/170 0s
> btrfs/171 1s
> btrfs/172 [not run] This test requires a valid $LOGWRITES_DEV
> btrfs/173 1s
> btrfs/174 1s
> btrfs/175 15s
> btrfs/176 6s
> btrfs/177 8s
> btrfs/178 1s
> btrfs/179 _check_btrfs_filesystem: filesystem on /dev/sdb2 is inconsistent
> (see /lkp/benchmarks/xfstests/results//btrfs/179.full for details)
This is known false alert.
When we have half dropped snapshots/subvolumes, btrfs check will report
false qgroup mismatch.
But if the kernel has fully dropped the subvolume/snapshot, the
btrfs-progs will report the same accounting as kernel.
I can workaround it by adding a "btrfs subv sync" to solve it for now.
The root fix is to make btrfs-check to do the same qgroup accounting for
half dropped subvolumes.
Thanks,
Qu
>
> btrfs/180 4s
> btrfs/181 3s
> btrfs/182 3s
> btrfs/183 1s
> btrfs/184 2s
> btrfs/185 1s
> btrfs/186 1s
> btrfs/187 192s
> btrfs/188 1s
> btrfs/189 2s
> btrfs/190 [not run] This test requires a valid $LOGWRITES_DEV
> btrfs/191 2s
> btrfs/192 [not run] This test requires a valid $LOGWRITES_DEV
> btrfs/193 2s
> btrfs/194 181s
> btrfs/195 489s
> btrfs/196 [not run] This test requires a valid $LOGWRITES_DEV
> btrfs/197 7s
> btrfs/198 3s
> btrfs/199 10s
> Ran: btrfs/150 btrfs/151 btrfs/152 btrfs/153 btrfs/155 btrfs/156 btrfs/157 btrfs/158 btrfs/159 btrfs/160 btrfs/161 btrfs/162 btrfs/163 btrfs/164 btrfs/165 btrfs/166 btrfs/167 btrfs/168 btrfs/169 btrfs/170 btrfs/171 btrfs/172 btrfs/173 btrfs/174 btrfs/175 btrfs/176 btrfs/177 btrfs/178 btrfs/179 btrfs/180 btrfs/181 btrfs/182 btrfs/183 btrfs/184 btrfs/185 btrfs/186 btrfs/187 btrfs/188 btrfs/189 btrfs/190 btrfs/191 btrfs/192 btrfs/193 btrfs/194 btrfs/195 btrfs/196 btrfs/197 btrfs/198 btrfs/199
> Not run: btrfs/156 btrfs/164 btrfs/172 btrfs/190 btrfs/192 btrfs/196
> Failures: btrfs/163 btrfs/179
> Failed 2 of 49 tests
>
>
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
>
>
> Thanks,
> Oliver Sang
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-11-26 11:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 8:56 kernel test robot
2020-11-26 11:09 ` Qu Wenruo [this message]
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=e8402d80-0255-ff89-f6a0-d0fc8b4ad827@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=oliver.sang@intel.com \
/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