From: Theodore Ts'o <tytso@mit.edu>
To: Brad Figg <brad.figg@canonical.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Ubuntu Ext4 regression testing
Date: Wed, 12 Sep 2012 22:18:18 -0400 [thread overview]
Message-ID: <20120913021818.GA27544@thunk.org> (raw)
In-Reply-To: <50511241.2090603@canonical.com>
On Wed, Sep 12, 2012 at 03:52:49PM -0700, Brad Figg wrote:
>
> The Ubuntu kernel team has been putting some automated testing
> infrastructure in place. We are very interested in engaging with
> the appropriate upstream developers. We have been running the
> xfstests that come as part of the autotest testing framework.
> Some of these tests fail or never complete when run against an
> Ext4 file-system.
Looking at your web page, it looks like xfstests is passing w/o any
problems for the set of tests that you are running with the 3.5 and
3.2 kernels.
The failures that you are seeing with 3.0 kernel looks funny; it looks
like you are running the tests one at a time, and after the file
system got corrupted with the fsstress run with test #13, your test
framework isn't repairing the file system with e2fsck -fy, so all of
the tests afterwards failed because the file system was corrupted. As
to why the test failed with 3.0, it's probably some problem we didn't
get backported to 3.0 for some reason. Quite frankly that's not
something I really worry about --- as far as I'm concerned, if it
can't be trivially backported as part of the stable@kernel.org
process, or after the stable coverage is finished, it's the distro's
responsibility to backport patches to their
old/antique/stable/enterprise/LTS kernels --- it's why the
distributions get paid the big bucks. :-)
Also, I noted that some of your failures on the older distributions
was due to missing userspace programs that were not installed on the
System Under Test (for example, "chacl").
As far as how I do my testing, I generally use "./check -g quick" or
"./check -g auto" --- where "-g auto" takes a lot longer, and there
are some known failure depending on specific set of mount options and
how the file system is created.
Here is my baseline that I had at the start of the 3.6 development
cycle. (There are some test failures that are on my todo list to
investigate more closely, but I keep a baseline to make sure things
don't regress.)
I have a script which handles doing all of this automatically using
KVM, with a single command I can run which takes a built kernel, runs
it using KVM, and passes the configuration options via the boot
command-line to a set of shell scripts run out of /etc/rc.local which
then runs xfstests in the various file system configurations.
- Ted
BEGIN TEST: Ext4 4k block Sat Jul 28 16:04:48 EDT 2012
MKFS_OPTIONS -- -q /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 213 214 215 219 221 223 225 228 230 235 236 237 240 243 245 246 247 248 249 255 256 257 258 263 271 277
Passed all 67 tests
END TEST: Ext4 4k block Sat Jul 28 16:33:53 EDT 2012
# This is a good way to test using ext4 for ext3 file systems
BEGIN TEST: Ext4 4k block w/nodelalloc and no extents Sat Jul 28 16:34:03 EDT 2012
MKFS_OPTIONS -- -q -O ^extents,^flex_bg,^uninit_bg /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity,nodelalloc /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 215 219 221 225 230 235 236 237 240 245 246 247 248 249 257 258 263 271 277
Passed all 60 tests
END TEST: Ext4 4k block w/nodelalloc and no extents Sat Jul 28 16:55:23 EDT 2012
# We care about this in Google, which is why I run it
BEGIN TEST: Ext4 4k block w/ no journal Sat Jul 28 16:55:26 EDT 2012
MKFS_OPTIONS -- -q -O ^has_journal /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity,noload /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 213 214 215 219 221 223 225 228 230 235 236 237 240 243 245 246 247 248 249 255 256 257 258 263 271 277
Passed all 67 tests
END TEST: Ext4 4k block w/ no journal Sat Jul 28 17:15:07 EDT 2012
# This is useful for testing page size != block size --- a big deal with
# architectures that have 16k pages, such as Power PC or Itanium with a
# 4k block --- we test for it using x86 and 1k blocks / 4k pages.
BEGIN TEST: Ext4 1k block Sat Jul 28 17:15:16 EDT 2012
MKFS_OPTIONS -- -q -b 1024 /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 213 214 215 219 221 223 225 228 230 235 236 237 240 243 245 246 247 248 249 255 256 257 258 263 271 277
Failures: 020
END TEST: Ext4 1k block Sat Jul 28 18:18:25 EDT 2012
# Useful for PCIe attached flash devices
BEGIN TEST: Ext4 4k block w/dioread_nolock Sat Jul 28 18:38:55 EDT 2012
MKFS_OPTIONS -- -q /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity,dioread_nolock /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 213 214 215 219 221 223 225 228 230 235 236 237 240 243 245 246 247 248 249 255 256 257 258 263 271 277
Failures: 091 263
END TEST: Ext4 4k block w/dioread_nolock Sat Jul 28 19:07:38 EDT 2012
BEGIN TEST: Ext4 4k block w/data=journal Sat Jul 28 19:07:45 EDT 2012
MKFS_OPTIONS -- -q /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity,data=journal /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 213 214 215 219 221 223 225 228 230 235 236 237 240 243 245 246 247 248 249 255 256 257 258 263 271 277
Failures: 223
END TEST: Ext4 4k block w/data=journal Sat Jul 28 19:33:26 EDT 2012
BEGIN TEST: Ext4 4k block w/bigalloc Sat Jul 28 19:33:35 EDT 2012
MKFS_OPTIONS -- -q -O bigalloc /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 075 076 079 088 091 105 112 113 117 120 123 124 126 128 129 130 131 135 141 169 184 193 198 207 210 211 212 213 214 215 219 221 223 225 228 230 235 236 237 240 243 245 246 247 248 249 257 258 263 271 277
Failures: 015 219 235
END TEST: Ext4 4k block w/bigalloc Sat Jul 28 19:52:41 EDT 2012
next prev parent reply other threads:[~2012-09-13 2:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 22:52 Ubuntu Ext4 regression testing Brad Figg
2012-09-12 23:01 ` Eric Sandeen
2012-09-12 23:15 ` Brad Figg
2012-09-13 0:20 ` Eric Sandeen
2012-09-13 0:41 ` Brad Figg
2012-09-13 1:51 ` Eric Sandeen
2012-09-13 2:04 ` Brad Figg
2012-09-13 2:09 ` Eric Sandeen
2012-09-13 2:17 ` Brad Figg
2012-09-13 2:24 ` Theodore Ts'o
2012-09-13 2:18 ` Theodore Ts'o [this message]
2012-09-13 2:50 ` Brad Figg
2012-09-19 3:41 ` 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=20120913021818.GA27544@thunk.org \
--to=tytso@mit.edu \
--cc=brad.figg@canonical.com \
--cc=linux-ext4@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).