From: "Theodore Tso" <tytso@mit.edu>
To: shuo chen <1289151713@qq.com>
Cc: adilger.kernel@dilger.ca, libaokun@linux.alibaba.com,
ack@suse.cz, ojaswin@linux.ibm.com, yi.zhang@huawei.com,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir
Date: Sun, 16 Aug 2026 23:12:33 -0400 [thread overview]
Message-ID: <aoJ4bJZNgNAt4pLD@mit.edu> (raw)
In-Reply-To: <tencent_BDF7C28D876E422418FB57474B765F0C1A09@qq.com>
Given the issues that were reported by the Sashiko and Syzbot issues,
I commend that you try using the kvm-xfstests[1] test appliance or the
related gce-xfstests[2] test appliance if you have access to Google
Compute Engine
[1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
[2] https://thunk.org/gce-xfstests
Since you are making changes to inline_data feature, you'd use it
soemthing like this:
% cd /usr/src/linux # replace with your kernel sources
% install-kconfig
% kbuild
% kvm-xfstests -c ext4/inline -g auto
You can also add some options to install-kconfig to enable extra
debugging, of which the most interesting are --kasan and --lockdep. I
would recommend doing your initial testing using just the plain
install-kconfig, and then once you are getting clean run, do separate
runs with the Kernel Address Sanitizer and the runtime locking
correctness validator.
The way I do my testing using gce-xfstests is to use a command like
this: "gce-xfstests ltm -c ext4/all -g auto" which will launch 12
VM's, for a variety of ext4 test scenarios (e.g., with bigalloc, fast
commit, 1k block sizes, etc.) You can of course try running
"kvm-xfstests -c ext4/all -g auto" but this will likely take around
24-36 hours depending on how fast your local storage test devices.
(Using gce-xfstest's lightweight test manager takes around 2 hours of
wall clock time, since the test VM's run in parallel.)
Cheers,
- Ted
prev parent reply other threads:[~2026-08-17 3:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 8:33 [PATCH] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir pipishuo
2026-08-13 8:49 ` sashiko-bot
2026-08-14 1:27 ` shuo chen
2026-08-14 3:31 ` Theodore Tso
2026-08-14 8:40 ` shuo chen
2026-08-14 13:57 ` Theodore Tso
2026-08-15 1:43 ` shuo chen
2026-08-16 15:02 ` [PATCH v2] " shuo chen
2026-08-16 15:16 ` sashiko-bot
2026-08-16 20:05 ` [syzbot ci] " syzbot ci
2026-08-17 3:12 ` Theodore Tso [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=aoJ4bJZNgNAt4pLD@mit.edu \
--to=tytso@mit.edu \
--cc=1289151713@qq.com \
--cc=ack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=yi.zhang@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.