From: "Theodore Ts'o" <tytso@mit.edu>
To: Baokun Li <libaokun1@huawei.com>
Cc: linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca,
jack@suse.cz, ritesh.list@gmail.com,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH v4 10/12] ext4: make ext4_es_insert_delayed_block() return void
Date: Mon, 12 Jun 2023 11:26:40 -0400 [thread overview]
Message-ID: <20230612152640.GA1500045@mit.edu> (raw)
In-Reply-To: <9af2b8d7-8ad4-96bf-6a30-587ad23cff59@huawei.com>
On Mon, Jun 12, 2023 at 11:47:07AM +0800, Baokun Li wrote:
> I'm very sorry, I didn't turn on encrypt or bigalloc when I tested it.
For complex series, it's helpful if you could run the equivalent of:
{gce,kvm}-xfstests -c ext4/all -g auto
It takes about 24 hours (plus or minus, depending on the speed of your
storage device; it will also take about twice as long if
CONFIG_LOCKDEP is enabled) if you use kvm-xfstests. Using
gce-xfstests with the ltm takes about around 1.75 hours (w/o LOCKDEP)
since it runs the tests in parallel, using separate VM's for each file
system config.
There are a small number of failures (especially flaky test failures),
however, (a) if a VM ever crashes, that's definitely a problem, and
(b) the ext4/4k config should be failure-free. For example, here's a
current "good" test run that I'm checking the dev branch against.
(Currently, we have some kind of issue with -c ext4/adv generic/475
that I'm still chasing down.)
- Ted
The failures seen below are known failures that we need to work
through. Bill Whitney is working on the bigalloc_1k shared/298
failure, for example. If you would like to work on one of the test
failures, especially if it's a file system config that you use in
production, please feel free to do so. :-) Also, if you are
interested in adapting the xfstests-bld codebase to support other
cloud services beyond Google Cloud Engine, again, let me know.
The gce-xfstests run below was generated using:
% gce-xfstests install-kconfig --lockdep
% gce-xfstests kbuild --dpkg
% gce-xfstests launch-ltm
% gce-xfstests ltm full
(Using the --dpkg is needed because is because there is a kexec bug
showing up when running on a Google Cloud VM's that I haven't been
able to fix, and it's been easier to just work around the kexec
problem. Kexec works just fine on kvm-xfstests, though, so there's no
need to use kbuild --dpkg if you are just using kvm-xfstests.)
TESTRUNID: ltm-20230611154922
KERNEL: kernel 6.4.0-rc5-xfstests-lockdep-00002-gdea9d8f7643f #170 SMP PREEMPT_DYNAMIC Sun Jun 11 15:21:52 EDT 2023 x86_64
CMDLINE: full
CPUS: 2
MEM: 7680
ext4/4k: 549 tests, 51 skipped, 6895 seconds
ext4/1k: 545 tests, 54 skipped, 10730 seconds
ext4/ext3: 541 tests, 140 skipped, 8547 seconds
ext4/encrypt: 527 tests, 3 failures, 158 skipped, 5783 seconds
Failures: generic/681 generic/682 generic/691
ext4/nojournal: 544 tests, 3 failures, 119 skipped, 8394 seconds
Failures: ext4/301 ext4/304 generic/455
ext4/ext3conv: 546 tests, 52 skipped, 9024 seconds
ext4/adv: 546 tests, 2 failures, 59 skipped, 8454 seconds
Failures: generic/477
Flaky: generic/475: 60% (3/5)
ext4/dioread_nolock: 547 tests, 51 skipped, 7883 seconds
ext4/data_journal: 545 tests, 2 failures, 119 skipped, 7605 seconds
Failures: generic/455 generic/484
ext4/bigalloc_4k: 521 tests, 56 skipped, 6650 seconds
ext4/bigalloc_1k: 521 tests, 1 failures, 64 skipped, 8074 seconds
Failures: shared/298
ext4/dax: 536 tests, 154 skipped, 5118 seconds
Totals: 6512 tests, 1077 skipped, 53 failures, 0 errors, 82214s
FSTESTIMG: gce-xfstests/xfstests-amd64-202305310154
FSTESTPRJ: gce-xfstests
FSTESTVER: blktests 676d42c (Thu, 2 Mar 2023 15:25:44 +0900)
FSTESTVER: e2fsprogs 1.47.0-2-4-gd4745c4a (Tue, 30 May 2023 16:20:44 -0400)
FSTESTVER: fio fio-3.31 (Tue, 9 Aug 2022 14:41:25 -0600)
FSTESTVER: fsverity v1.5-6-g5d6f7c4 (Mon, 30 Jan 2023 23:22:45 -0800)
FSTESTVER: ima-evm-utils v1.3.2 (Wed, 28 Oct 2020 13:18:08 -0400)
FSTESTVER: nvme-cli v1.16 (Thu, 11 Nov 2021 13:09:06 -0800)
FSTESTVER: quota v4.05-53-gd90b7d5 (Tue, 6 Dec 2022 12:59:03 +0100)
FSTESTVER: util-linux v2.38.1 (Thu, 4 Aug 2022 11:06:21 +0200)
FSTESTVER: xfsprogs v6.1.1 (Fri, 13 Jan 2023 19:06:37 +0100)
FSTESTVER: xfstests-bld 6599baba-dirty (Wed, 19 Apr 2023 23:16:10 -0400)
FSTESTVER: xfstests v2023.04.09-8-g2525b7af5-dirty (Wed, 19 Apr 2023 13:42:14 -0400)
FSTESTVER: zz_build-distro bullseye
FSTESTSET: -g auto
FSTESTOPT: aex
next prev parent reply other threads:[~2023-06-12 15:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 3:38 [PATCH v4 00/12] ext4: fix WARNING in ext4_da_update_reserve_space Baokun Li
2023-04-24 3:38 ` [PATCH v4 01/12] ext4: only update i_reserved_data_blocks on successful block allocation Baokun Li
2023-04-24 3:38 ` [PATCH v4 02/12] ext4: add a new helper to check if es must be kept Baokun Li
2023-05-03 12:57 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 03/12] ext4: factor out __es_alloc_extent() and __es_free_extent() Baokun Li
2023-05-03 14:28 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 04/12] ext4: use pre-allocated es in __es_insert_extent() Baokun Li
2023-05-03 14:28 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 05/12] ext4: use pre-allocated es in __es_remove_extent() Baokun Li
2023-05-03 14:29 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 06/12] ext4: using nofail preallocation in ext4_es_remove_extent() Baokun Li
2023-05-03 14:30 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 07/12] ext4: using nofail preallocation in ext4_es_insert_delayed_block() Baokun Li
2023-05-03 14:31 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 08/12] ext4: using nofail preallocation in ext4_es_insert_extent() Baokun Li
2023-05-03 14:32 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 09/12] ext4: make ext4_es_remove_extent() return void Baokun Li
2023-05-03 14:32 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 10/12] ext4: make ext4_es_insert_delayed_block() " Baokun Li
2023-05-03 14:32 ` Jan Kara
2023-06-10 19:03 ` Theodore Ts'o
2023-06-12 3:04 ` Theodore Ts'o
2023-06-12 3:47 ` Baokun Li
2023-06-12 15:26 ` Theodore Ts'o [this message]
2023-06-13 1:36 ` Baokun Li
2023-04-24 3:38 ` [PATCH v4 11/12] ext4: make ext4_es_insert_extent() " Baokun Li
2023-05-03 14:32 ` Jan Kara
2023-04-24 3:38 ` [PATCH v4 12/12] ext4: make ext4_zeroout_es() " Baokun Li
2023-05-03 14:33 ` Jan Kara
2023-05-24 7:30 ` [PATCH v4 00/12] ext4: fix WARNING in ext4_da_update_reserve_space Baokun Li
2023-06-09 3:14 ` Theodore Ts'o
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=20230612152640.GA1500045@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.