public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Baokun Li <libaokun1@huawei.com>
To: Theodore Ts'o <tytso@mit.edu>
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>,
	Baokun Li <libaokun1@huawei.com>
Subject: Re: [PATCH v4 10/12] ext4: make ext4_es_insert_delayed_block() return void
Date: Tue, 13 Jun 2023 09:36:52 +0800	[thread overview]
Message-ID: <db478a24-39f5-3cef-8814-89406ce4d2ca@huawei.com> (raw)
In-Reply-To: <20230612152640.GA1500045@mit.edu>

On 2023/6/12 23:26, Theodore Ts'o wrote:
> 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.

It looks very good and I'll try to use it.

I'll try to locate some test case failures when I get free.

>
> 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
>
I was using native xfstests for my previous tests, and I feel that

gce-xfstests is much easier to use and the results are very clear,

thanks for the great recommendation!

-- 
With Best Regards,
Baokun Li
.

  reply	other threads:[~2023-06-13  1:36 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
2023-06-13  1:36           ` Baokun Li [this message]
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=db478a24-39f5-3cef-8814-89406ce4d2ca@huawei.com \
    --to=libaokun1@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox