Refreshed rootfs.img for kvm-xfstests

Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

There is an updated rootfs.img file available at:

    https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests

It includes the latest updates from the xfstests-dev upstream, as well
as updated file system utilities from debian-backports.  It also adds
support for the new encryption teests from Eric Biggers (for this
reason the xfsprogs in this image includes an out-of-tree patch to
allow xfs_io to set the encryption policy).

We also now skip all of the reflink/dedupe tests when running tests
for ext4, to speed up our testing.

This release of kvm-xfstests now supports f2fs (as well as btrfs,
ext2, ext4, overlay, tmpfs, and xfs).

The gce-xfstests driver has been updated to support the latest gcloud
SDK and Debian releases as well as the above changes.  For more
information about this test framework, please see:

    http://thunk.org/gce-xfstests

						- Ted

e2fsprogs	v1.43.3-30-g8df85fb (Sun, 4 Sep 2016 21:32:35 -0400)
fio		fio-2.16 (Mon, 19 Dec 2016 23:12:56 -0700)
quota		2b37958 (Tue, 9 Aug 2016 19:17:56 +0200)
xfsprogs	v4.9.0-1-g07d66eb (Sat, 7 Jan 2017 23:27:26 -0500)
xfstests-bld	39124a6 (Mon, 9 Jan 2017 11:09:14 -0500)
xfstests	linux-v3.8-1306-gbeffdf1 (Sun, 8 Jan 2017 20:30:22 -0500)
						

Re: Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

[-- Attachment #1: Type: text/plain, Size: 3898 bytes --]

On Mon, Jan 09, 2017 at 06:14:50PM -0500, Theodore Ts'o wrote:
> There is an updated rootfs.img file available at:
> 
>     https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests

... and here are the latest test results using gce-xfstests on the
ext4.git's dev branch (which includes Roman's fixes).  I've annotated
the test failures report here and attached a compressed copy of the
runtests.log file:

CMDLINE: full
FSTESTIMG: gce-xfstests/xfstests-201701091217
FSTESTVER: e2fsprogs	v1.43.3-30-g8df85fb (Sun, 4 Sep 2016 21:32:35 -0400)
FSTESTVER: fio		fio-2.16 (Mon, 19 Dec 2016 23:12:56 -0700)
FSTESTVER: quota		2b37958 (Tue, 9 Aug 2016 19:17:56 +0200)
FSTESTVER: xfsprogs	v4.9.0-1-g07d66eb (Sat, 7 Jan 2017 23:27:26 -0500)
FSTESTVER: xfstests-bld	39124a6 (Mon, 9 Jan 2017 11:09:14 -0500)
FSTESTVER: xfstests	linux-v3.8-1306-gbeffdf1 (Sun, 8 Jan 2017 20:30:22 -0500)
FSTESTVER: kernel	4.10.0-rc3-ext4-00014-g2b3864b32403 #195 SMP Mon Jan 9 01:32:06 EST 2017 x86_64
FSTESTCFG: "all"
FSTESTSET: "-g auto"
FSTESTEXC: ""
FSTESTOPT: "aex"
MNTOPTS: ""
CPUS: "2"
MEM: "7477.96"
MEM: 7680 MB (Max capacity)
BEGIN TEST 4k: Ext4 4k block Mon Jan  9 12:26:16 EST 2017
Passed all 245 tests
BEGIN TEST 1k: Ext4 1k block Mon Jan  9 13:16:48 EST 2017
Failures: generic/018 generic/270 generic/273
   generic/018 -- defrag test failure --- ignore
   generic/270 -- known lockdep problem in quota code
   generic/273 -- we aren't reserving enough blocks on a 2GB 1k file system,
       so ENOSPC block reservation test is failing.
BEGIN TEST ext3: Ext4 4k block emulating ext3 Mon Jan  9 14:13:51 EST 2017
Failures: generic/382
   generic/382 -- quota test which doesn't take indirect blocks into account.
BEGIN TEST encrypt: Ext4 encryption Mon Jan  9 14:57:29 EST 2017
Failures: ext4/022 generic/382
   ext4/022 -- ENOSPC test involving encryption and xattr
   generic/382 -- quota test which should be suppresed with encryption
BEGIN TEST nojournal: Ext4 4k block w/ no journal Mon Jan  9 15:22:05 EST 2017
Failures: ext4/301
   ext4/301 -- defrag failure with no journal?
BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Mon Jan  9 16:07:55 EST 2017
Failures: generic/347
   generic/347 --- file system got corrupted?!?
BEGIN TEST adv: Ext4 advanced features (inline_data, metadata_csum, 64bit) Mon Jan  9 16:53:22 EST 2017
Failures: generic/396 generic/399
   generic/396 --- fscrypt releated: file system got corrupted?!?
   generic/399 --- fscrypt releated: file system never filled up?!?
BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Mon Jan  9 17:39:38 EST 2017
Passed all 245 tests
BEGIN TEST data_journal: Ext4 4k block w/data=journal Mon Jan  9 18:25:55 EST 2017
Failures: generic/347
   generic/347 -- file system got corruptd?!?
BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Mon Jan  9 19:35:00 EST 2017
Failures: ext4/004 generic/204 generic/219 generic/235 generic/273 generic/399
   ext4/004 --- dump restore failure (with bigalloc --- not surprising)
   generic/204 --- ENOSPC during test
   generic/219 --- too many blocks used (quota accounting)
   generic/235 --- clusters vs blocks accounting in quota code
   generic/273 --- not reserving enough space (porter not complete)
   generic/399 --- fscrypt releated: file system corrupted?!?
BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Mon Jan  9 20:17:46 EST 2017
Failures: ext4/004 generic/204 generic/235 generic/273nnn
   ext4/004 --- dump restore failure (with bigalloc --- not surprising)
   generic/204 --- ENOSPC during test
   generic/235 --- clusters vs blocks accounting in quota code
   generic/273 --- not reserving enough space (porter not complete)?!?

Some of these are test bugs that we should fix or suppress.  Others,
such as the new encryption tests causing corrupted file systems in the
more exotic file system configurations, are definitely bugs that we
need to fix.

						- Ted

[-- Attachment #2: runtests.log.xz --]
[-- Type: application/x-xz, Size: 22340 bytes --]

Re: Refreshed rootfs.img for kvm-xfstests

[Roman Penyaev]

On Tue, Jan 10, 2017 at 4:38 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Jan 09, 2017 at 06:14:50PM -0500, Theodore Ts'o wrote:
>> There is an updated rootfs.img file available at:
>>
>>     https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests
>
> ... and here are the latest test results using gce-xfstests on the
> ext4.git's dev branch (which includes Roman's fixes).  I've annotated
> the test failures report here and attached a compressed copy of the
> runtests.log file:
>
> CMDLINE: full
> FSTESTIMG: gce-xfstests/xfstests-201701091217
> FSTESTVER: e2fsprogs    v1.43.3-30-g8df85fb (Sun, 4 Sep 2016 21:32:35 -0400)
> FSTESTVER: fio          fio-2.16 (Mon, 19 Dec 2016 23:12:56 -0700)
> FSTESTVER: quota                2b37958 (Tue, 9 Aug 2016 19:17:56 +0200)
> FSTESTVER: xfsprogs     v4.9.0-1-g07d66eb (Sat, 7 Jan 2017 23:27:26 -0500)
> FSTESTVER: xfstests-bld 39124a6 (Mon, 9 Jan 2017 11:09:14 -0500)
> FSTESTVER: xfstests     linux-v3.8-1306-gbeffdf1 (Sun, 8 Jan 2017 20:30:22 -0500)
> FSTESTVER: kernel       4.10.0-rc3-ext4-00014-g2b3864b32403 #195 SMP Mon Jan 9 01:32:06 EST 2017 x86_64
> FSTESTCFG: "all"
> FSTESTSET: "-g auto"
> FSTESTEXC: ""
> FSTESTOPT: "aex"
> MNTOPTS: ""
> CPUS: "2"
> MEM: "7477.96"
> MEM: 7680 MB (Max capacity)
> BEGIN TEST 4k: Ext4 4k block Mon Jan  9 12:26:16 EST 2017
> Passed all 245 tests
> BEGIN TEST 1k: Ext4 1k block Mon Jan  9 13:16:48 EST 2017
> Failures: generic/018 generic/270 generic/273
>    generic/018 -- defrag test failure --- ignore
>    generic/270 -- known lockdep problem in quota code
>    generic/273 -- we aren't reserving enough blocks on a 2GB 1k file system,
>        so ENOSPC block reservation test is failing.
> BEGIN TEST ext3: Ext4 4k block emulating ext3 Mon Jan  9 14:13:51 EST 2017
> Failures: generic/382
>    generic/382 -- quota test which doesn't take indirect blocks into account.
> BEGIN TEST encrypt: Ext4 encryption Mon Jan  9 14:57:29 EST 2017
> Failures: ext4/022 generic/382
>    ext4/022 -- ENOSPC test involving encryption and xattr
>    generic/382 -- quota test which should be suppresed with encryption
> BEGIN TEST nojournal: Ext4 4k block w/ no journal Mon Jan  9 15:22:05 EST 2017
> Failures: ext4/301
>    ext4/301 -- defrag failure with no journal?
> BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Mon Jan  9 16:07:55 EST 2017
> Failures: generic/347
>    generic/347 --- file system got corrupted?!?
> BEGIN TEST adv: Ext4 advanced features (inline_data, metadata_csum, 64bit) Mon Jan  9 16:53:22 EST 2017
> Failures: generic/396 generic/399
>    generic/396 --- fscrypt releated: file system got corrupted?!?
>    generic/399 --- fscrypt releated: file system never filled up?!?
> BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Mon Jan  9 17:39:38 EST 2017
> Passed all 245 tests
> BEGIN TEST data_journal: Ext4 4k block w/data=journal Mon Jan  9 18:25:55 EST 2017
> Failures: generic/347
>    generic/347 -- file system got corruptd?!?
> BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Mon Jan  9 19:35:00 EST 2017
> Failures: ext4/004 generic/204 generic/219 generic/235 generic/273 generic/399
>    ext4/004 --- dump restore failure (with bigalloc --- not surprising)
>    generic/204 --- ENOSPC during test
>    generic/219 --- too many blocks used (quota accounting)
>    generic/235 --- clusters vs blocks accounting in quota code
>    generic/273 --- not reserving enough space (porter not complete)
>    generic/399 --- fscrypt releated: file system corrupted?!?
> BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Mon Jan  9 20:17:46 EST 2017
> Failures: ext4/004 generic/204 generic/235 generic/273nnn
>    ext4/004 --- dump restore failure (with bigalloc --- not surprising)
>    generic/204 --- ENOSPC during test
>    generic/235 --- clusters vs blocks accounting in quota code
>    generic/273 --- not reserving enough space (porter not complete)?!?
>
> Some of these are test bugs that we should fix or suppress.  Others,
> such as the new encryption tests causing corrupted file systems in the
> more exotic file system configurations, are definitely bugs that we
> need to fix.
>

I retested the following configurations on 69973b830859 ("Linux 4.9"):

./kvm-xfstests.sh -c nojournal    ext4/301
./kvm-xfstests.sh -c ext3conv     generic/347
./kvm-xfstests.sh -c adv          generic/396 generic/399
./kvm-xfstests.sh -c data_journal generic/347
./kvm-xfstests.sh -c bigalloc     generic/399
./kvm-xfstests.sh -c bigalloc_1k  generic/273

all of the tests from list have failed.

This is not very much helpful, but at least that can be a starting
point for bisecting.

When there was a successful xfstests run at least for some of
the configurations?  Would be nice to have a "good" reference.

--
Roman

Re: Refreshed rootfs.img for kvm-xfstests

[Roman Penyaev]

On Tue, Jan 10, 2017 at 1:48 PM, Roman Penyaev
<roman.penyaev@profitbricks.com> wrote:
> On Tue, Jan 10, 2017 at 4:38 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Mon, Jan 09, 2017 at 06:14:50PM -0500, Theodore Ts'o wrote:
>>> There is an updated rootfs.img file available at:
>>>
>>>     https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests
>>
>> ... and here are the latest test results using gce-xfstests on the
>> ext4.git's dev branch (which includes Roman's fixes).  I've annotated
>> the test failures report here and attached a compressed copy of the
>> runtests.log file:
>>
>> CMDLINE: full
>> FSTESTIMG: gce-xfstests/xfstests-201701091217
>> FSTESTVER: e2fsprogs    v1.43.3-30-g8df85fb (Sun, 4 Sep 2016 21:32:35 -0400)
>> FSTESTVER: fio          fio-2.16 (Mon, 19 Dec 2016 23:12:56 -0700)
>> FSTESTVER: quota                2b37958 (Tue, 9 Aug 2016 19:17:56 +0200)
>> FSTESTVER: xfsprogs     v4.9.0-1-g07d66eb (Sat, 7 Jan 2017 23:27:26 -0500)
>> FSTESTVER: xfstests-bld 39124a6 (Mon, 9 Jan 2017 11:09:14 -0500)
>> FSTESTVER: xfstests     linux-v3.8-1306-gbeffdf1 (Sun, 8 Jan 2017 20:30:22 -0500)
>> FSTESTVER: kernel       4.10.0-rc3-ext4-00014-g2b3864b32403 #195 SMP Mon Jan 9 01:32:06 EST 2017 x86_64
>> FSTESTCFG: "all"
>> FSTESTSET: "-g auto"
>> FSTESTEXC: ""
>> FSTESTOPT: "aex"
>> MNTOPTS: ""
>> CPUS: "2"
>> MEM: "7477.96"
>> MEM: 7680 MB (Max capacity)
>> BEGIN TEST 4k: Ext4 4k block Mon Jan  9 12:26:16 EST 2017
>> Passed all 245 tests
>> BEGIN TEST 1k: Ext4 1k block Mon Jan  9 13:16:48 EST 2017
>> Failures: generic/018 generic/270 generic/273
>>    generic/018 -- defrag test failure --- ignore
>>    generic/270 -- known lockdep problem in quota code
>>    generic/273 -- we aren't reserving enough blocks on a 2GB 1k file system,
>>        so ENOSPC block reservation test is failing.
>> BEGIN TEST ext3: Ext4 4k block emulating ext3 Mon Jan  9 14:13:51 EST 2017
>> Failures: generic/382
>>    generic/382 -- quota test which doesn't take indirect blocks into account.
>> BEGIN TEST encrypt: Ext4 encryption Mon Jan  9 14:57:29 EST 2017
>> Failures: ext4/022 generic/382
>>    ext4/022 -- ENOSPC test involving encryption and xattr
>>    generic/382 -- quota test which should be suppresed with encryption
>> BEGIN TEST nojournal: Ext4 4k block w/ no journal Mon Jan  9 15:22:05 EST 2017
>> Failures: ext4/301
>>    ext4/301 -- defrag failure with no journal?
>> BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Mon Jan  9 16:07:55 EST 2017
>> Failures: generic/347
>>    generic/347 --- file system got corrupted?!?
>> BEGIN TEST adv: Ext4 advanced features (inline_data, metadata_csum, 64bit) Mon Jan  9 16:53:22 EST 2017
>> Failures: generic/396 generic/399
>>    generic/396 --- fscrypt releated: file system got corrupted?!?
>>    generic/399 --- fscrypt releated: file system never filled up?!?
>> BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Mon Jan  9 17:39:38 EST 2017
>> Passed all 245 tests
>> BEGIN TEST data_journal: Ext4 4k block w/data=journal Mon Jan  9 18:25:55 EST 2017
>> Failures: generic/347
>>    generic/347 -- file system got corruptd?!?
>> BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Mon Jan  9 19:35:00 EST 2017
>> Failures: ext4/004 generic/204 generic/219 generic/235 generic/273 generic/399
>>    ext4/004 --- dump restore failure (with bigalloc --- not surprising)
>>    generic/204 --- ENOSPC during test
>>    generic/219 --- too many blocks used (quota accounting)
>>    generic/235 --- clusters vs blocks accounting in quota code
>>    generic/273 --- not reserving enough space (porter not complete)
>>    generic/399 --- fscrypt releated: file system corrupted?!?
>> BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Mon Jan  9 20:17:46 EST 2017
>> Failures: ext4/004 generic/204 generic/235 generic/273nnn
>>    ext4/004 --- dump restore failure (with bigalloc --- not surprising)
>>    generic/204 --- ENOSPC during test
>>    generic/235 --- clusters vs blocks accounting in quota code
>>    generic/273 --- not reserving enough space (porter not complete)?!?
>>
>> Some of these are test bugs that we should fix or suppress.  Others,
>> such as the new encryption tests causing corrupted file systems in the
>> more exotic file system configurations, are definitely bugs that we
>> need to fix.
>>
>
> I retested the following configurations on 69973b830859 ("Linux 4.9"):
>
> ./kvm-xfstests.sh -c nojournal    ext4/301
> ./kvm-xfstests.sh -c ext3conv     generic/347
> ./kvm-xfstests.sh -c adv          generic/396 generic/399
> ./kvm-xfstests.sh -c data_journal generic/347
> ./kvm-xfstests.sh -c bigalloc     generic/399
> ./kvm-xfstests.sh -c bigalloc_1k  generic/273
>
> all of the tests from list have failed.

I executed the list above on these kernels:

c8d2bc9bc39e ("Linux 4.8")
523d939ef98f ("Linux 4.7")
2dcd0af568b0 ("Linux 4.6")
b562e44f507e ("Linux 4.5")

and the picture stays the same: tests continue to fail.
(once I saw '-c data_journal generic/347' on 4.6 has passed, but
 I failed to repeat this success).

Theodore, do you have successful reference run for these configurations?

Because, I am pretty much confused: either I do something completely
wrong (seems checking "FSTESTVER: kernel" line should be enough to
be sure, that tests are executed on desired kernel version) or those
tests were broken long time ago.

--
Roman

>
> This is not very much helpful, but at least that can be a starting
> point for bisecting.
>
> When there was a successful xfstests run at least for some of
> the configurations?  Would be nice to have a "good" reference.
>
> --
> Roman

Re: Refreshed rootfs.img for kvm-xfstests

[Eric Biggers]

On Tue, Jan 10, 2017 at 01:48:03PM +0100, Roman Penyaev wrote:
> 
> I retested the following configurations on 69973b830859 ("Linux 4.9"):
> 
> ./kvm-xfstests.sh -c nojournal    ext4/301
> ./kvm-xfstests.sh -c ext3conv     generic/347
> ./kvm-xfstests.sh -c adv          generic/396 generic/399
> ./kvm-xfstests.sh -c data_journal generic/347
> ./kvm-xfstests.sh -c bigalloc     generic/399
> ./kvm-xfstests.sh -c bigalloc_1k  generic/273
> 
> all of the tests from list have failed.
> 
> This is not very much helpful, but at least that can be a starting
> point for bisecting.
> 
> When there was a successful xfstests run at least for some of
> the configurations?  Would be nice to have a "good" reference.
> 

Hi Roman,

Generally these have been broken for a while, or in the case of generic/396 and
generic/399 are new tests which are exposing bugs.  A few of these I was already
aware of but just haven't had time to get to:

- the failure of generic/347 in data journalling mode is intermittent
- the failure of generic/396 in "adv" mode is related to the use of the inline
  data feature, apparently caused by ext4_convert_inline_data() corrupting an
  empty directory
- failure of generic/399 in some configurations

If you're interested in looking into any of these failing tests and either
fixing the kernel or fixing the test as appropriate, please feel free to!

Thanks,

Eric

Re: Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

On Tue, Jan 10, 2017 at 04:07:49PM +0100, Roman Penyaev wrote:
> > I retested the following configurations on 69973b830859 ("Linux 4.9"):
> >
> > ./kvm-xfstests.sh -c nojournal    ext4/301
> > ./kvm-xfstests.sh -c ext3conv     generic/347
> > ./kvm-xfstests.sh -c adv          generic/396 generic/399
> > ./kvm-xfstests.sh -c data_journal generic/347
> > ./kvm-xfstests.sh -c bigalloc     generic/399
> > ./kvm-xfstests.sh -c bigalloc_1k  generic/273
> >
> > all of the tests from list have failed.
> 
> I executed the list above on these kernels:
> 
> c8d2bc9bc39e ("Linux 4.8")
> 523d939ef98f ("Linux 4.7")
> 2dcd0af568b0 ("Linux 4.6")
> b562e44f507e ("Linux 4.5")
> 
> and the picture stays the same: tests continue to fail.
> (once I saw '-c data_journal generic/347' on 4.6 has passed, but
>  I failed to repeat this success).

Hi Roman,

It's important to remember that xfstests keep adding new tests and
changing existing ones.  So for example, here below is a test of
4.7.0-rc1 with the ext4 changes that went into 4.8 during the merge
window.  You'll see that these test failures above mostly aren't
represented.  (One exception is ext4/301 in nojournal mode; that's
been one that has been failing for a while.  As far as I know, main
user of nojournal mode is Google, and we don't use e4defrag, so it's
not been a high priority for meto track down.)

The test report attached below was run on July 17th, using xfstests
git repo from March 15th, and so a number of these tests simply
weren't not in the xfstests yet:

% git log --reverse --pretty=%cd\n tests/generic/347 | head -1
Mon May 9 10:55:24 2016 +1000n
% git log --reverse --pretty=%cd\n tests/generic/273 | head -1
Tue Mar 26 11:43:49 2013 -0500n
=% git log --reverse --pretty=%cd\n tests/generic/396 | head -1
Sat Dec 24 16:47:12 2016 +0800n
% git log --reverse --pretty=%cd\n tests/generic/399 | head -1
Sat Dec 24 16:48:58 2016 +0800n

So very often a git bisect isn't the best way to debug a test failure.
In some cases a bug that was found in another file system (such as
btrfs, or f2fs) when introduced as a generic test, ends up tickling a
bug (often a different kind of bug with different symptoms) in ext4.

Cheers,

						- Ted

Subject: xfstests results 201607170254 - 4.7.0-rc1-ext4-00021-g7bc9491

CMDLINE: full
FSTESTVER: e2fsprogs    v1.43.1-22-g25c4a20 (Wed, 8 Jun 2016 18:11:27 -0400)
FSTESTVER: fio          fio-2.6-8-ge6989e1 (Thu, 4 Feb 2016 12:09:48 -0700)
FSTESTVER: quota                81aca5c (Tue, 12 Jul 2016 16:15:45 +0200)
FSTESTVER: xfsprogs     v4.5.0 (Tue, 15 Mar 2016 15:25:56 +1100)
FSTESTVER: xfstests-bld 4247cb8 (Sat, 16 Jul 2016 21:58:00 -0400)
FSTESTVER: xfstests     linux-v3.8-1105-gacd7210 (Fri, 15 Jul 2016 11:16:57 -0400)
FSTESTVER: kernel       4.7.0-rc1-ext4-00021-g7bc9491 #320 SMP Sun Jul 17 02:51:56 EDT 2016 x86_64
FSTESTCFG: "4k 1k ext3 encrypt nojournal ext3conv adv dioread_nolock data_journal bigalloc bigalloc_1k"
FSTESTSET: "-g auto"
FSTESTEXC: ""
FSTESTOPT: "aex"
MNTOPTS: ""
CPUS: "2"
MEM: "7496.82"
MEM: 7680 MB (Max capacity)
BEGIN TEST 4k: Ext4 4k block Sun Jul 17 02:55:55 EDT 2016
Passed all 224 tests
BEGIN TEST 1k: Ext4 1k block Sun Jul 17 03:44:54 EDT 2016
Failures: generic/018 generic/273
BEGIN TEST ext3: Ext4 4k block emulating ext3 Sun Jul 17 04:37:46 EDT 2016
Passed all 180 tests
BEGIN TEST encrypt: Ext4 encryption Sun Jul 17 05:25:58 EDT 2016
Failures: ext4/020 generic/269
BEGIN TEST nojournal: Ext4 4k block w/ no journal Sun Jul 17 05:52:50 EDT 2016
Failures: ext4/301
BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Sun Jul 17 06:36:35 EDT 2016
Failures: generic/347
BEGIN TEST adv: Ext4 advanced features (inline_data, metadata_csum, 64bit) Sun Jul 17 07:23:25 EDT 2016
Passed all 223 tests
BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Sun Jul 17 08:12:27 EDT 2016
Passed all 224 tests
BEGIN TEST data_journal: Ext4 4k block w/data=journal Sun Jul 17 09:01:46 EDT 2016
Failures: generic/018 generic/347
BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Sun Jul 17 10:09:25 EDT 2016
Failures: ext4/004 generic/204 generic/219 generic/235 generic/273
BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Sun Jul 17 11:02:40 EDT 2016
Failures: ext4/004 generic/204 generic/235 generic/273

Re: Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

On Sat, Jul 23, 2016 at 07:06:34PM -0400, Eric Whitney wrote:
> I've tried the image - the awk and quota tools problems are fixed, but the
> missing files in root noted above are still missing.

And that was due to rsync not being available in the build chroot.
I've uploaded a fixed tar.gz file.

Thanks for the feedback!  The armhf build driven from an automated
(and now debugged) build script, so we hopefully won't have any issues
moving forward.

						- Ted

Re: Refreshed rootfs.img for kvm-xfstests

[Eric Whitney]

* Theodore Ts'o <tytso@mit.edu>:
> On Thu, Jul 21, 2016 at 04:22:39PM -0400, Eric Whitney wrote:
> > I've tested this version of the ARM test appliance using the 4k test config
> > on a Pandaboard with a 4.7-rc7 kernel, and have discovered a few problems with
> > the file system image as discussed in today's concall (the upshot was that the
> > build process might be failing somewhere along the way and producing an
> > incomplete image):
> > 
> > Several files needed to run the appliance are missing from /root - test-env,
> > test-conf, /conf (and its contents), and runtests.sh.  Copying them in
> > from xfstests-bld solved that.
> > 
> > /usr/bin/awk points to an executable in Ted's home directory.  Relinking to
> > /usr/bin/gawk fixed things up well enough.
> 
> The first was caused a bug in how a rsync'ed the source tree to the
> armhf build host.  Debian's build systems have a firewall that prevent
> git from working correctly, so I have to rsync the source tree up
> build host, and this broke the git tree so the automated generation of
> the *.ver files broke, which in turn aborted the installation of the
> quota tools.
> 
> The second problem had to do with how fakechroot (used because I don't
> have root on the arm build host) handles symlinks.  Fixed by using the
> "symlinks" program rewrite the absolute symlinks to relative symlinks.
> 
> I've uploaded an updated armmf_root_fs.tar.gz; please give it a try!
> 
> Cheers,
> 
> 							- Ted

I've tried the image - the awk and quota tools problems are fixed, but the
missing files in root noted above are still missing.  I was able to get a
successful 4k run after copying the missing files into the root directory
from the xfstests-bld tree.  There are a number of test failures that didn't
occur in my test baseline, much as before, but nothing yet obviously caused
by the test appliance itself.

Thanks,
Eric

Re: Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

On Thu, Jul 21, 2016 at 04:22:39PM -0400, Eric Whitney wrote:
> I've tested this version of the ARM test appliance using the 4k test config
> on a Pandaboard with a 4.7-rc7 kernel, and have discovered a few problems with
> the file system image as discussed in today's concall (the upshot was that the
> build process might be failing somewhere along the way and producing an
> incomplete image):
> 
> Several files needed to run the appliance are missing from /root - test-env,
> test-conf, /conf (and its contents), and runtests.sh.  Copying them in
> from xfstests-bld solved that.
> 
> /usr/bin/awk points to an executable in Ted's home directory.  Relinking to
> /usr/bin/gawk fixed things up well enough.

The first was caused a bug in how a rsync'ed the source tree to the
armhf build host.  Debian's build systems have a firewall that prevent
git from working correctly, so I have to rsync the source tree up
build host, and this broke the git tree so the automated generation of
the *.ver files broke, which in turn aborted the installation of the
quota tools.

The second problem had to do with how fakechroot (used because I don't
have root on the arm build host) handles symlinks.  Fixed by using the
"symlinks" program rewrite the absolute symlinks to relative symlinks.

I've uploaded an updated armmf_root_fs.tar.gz; please give it a try!

Cheers,

							- Ted

Re: Refreshed rootfs.img for kvm-xfstests

[Eric Whitney]

* Theodore Ts'o <tytso@mit.edu>:
> There is an updated rootfs.img file available at:
> 
>     https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests
> 
> It includes the latest updates from the xfstests-dev upstream.
> 
> There is a new set of more nicely formatted, but more importantly,
> better organized and expanded documentation for xfstests-bld,
> kvm-xfstests, and gce-xfstests.  The new documentation is formatted in
> Markdown, and can be browsed starting at:
> 
> https://github.com/tytso/xfstests-bld/blob/master/README.md
> 
> This release also includes an updated armhf chroot distribution,
> armhf_root_fs.tar.gz.  This was previously released in the testing
> subdirectory, but it is now built as an synchrnoized part of the
> kvm-xfstests root_fs.img release process.  Very rough instructions for
> using this tarball can be found here:
> 
> https://github.com/tytso/xfstests-bld/blob/master/Documentation/android-xfstests.md

I've tested this version of the ARM test appliance using the 4k test config
on a Pandaboard with a 4.7-rc7 kernel, and have discovered a few problems with
the file system image as discussed in today's concall (the upshot was that the
build process might be failing somewhere along the way and producing an
incomplete image):

Several files needed to run the appliance are missing from /root - test-env,
test-conf, /conf (and its contents), and runtests.sh.  Copying them in
from xfstests-bld solved that.

/usr/bin/awk points to an executable in Ted's home directory.  Relinking to
/usr/bin/gawk fixed things up well enough.

With these changes, I was able to get a complete 4k run with some
discrepancies relative to my ARM baseline:

As reported in the output log produced by runtests.sh, it appears that the
quota user tools are not installed; quota-related xfstests were not run,
and the tools are missing from /root/xfstests/bin where they are found on the
x86_64 image.

Several tests using dm failed involving the error and flakey targets.  Some
succeeded in my baseline, and some are new since the baseline.  They need
a closer look to see what's going on - there's no immediate evidence the
root fs image is responsible.

Otherwise, this is an easy and convenient way to run the test appliance on
ARM.  Thanks!

Eric

> 
> If there is anyone who is interested and has time to look into
> creating an automated test runner for armhf_root_fs.tar.gz, ala
> kvm-xfstests and gce-xfstests, but using the Android adb and fastboot
> utilities to control the Android device, please let me know.  I'd love
> to find a volunteer interested in working on this project!
> 
>    	  	    	       	  	     	  - Ted
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

There is an updated rootfs.img file available at:

    https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests

It includes the latest updates from the xfstests-dev upstream.

There is a new set of more nicely formatted, but more importantly,
better organized and expanded documentation for xfstests-bld,
kvm-xfstests, and gce-xfstests.  The new documentation is formatted in
Markdown, and can be browsed starting at:

https://github.com/tytso/xfstests-bld/blob/master/README.md

This release also includes an updated armhf chroot distribution,
armhf_root_fs.tar.gz.  This was previously released in the testing
subdirectory, but it is now built as an synchrnoized part of the
kvm-xfstests root_fs.img release process.  Very rough instructions for
using this tarball can be found here:

https://github.com/tytso/xfstests-bld/blob/master/Documentation/android-xfstests.md

If there is anyone who is interested and has time to look into
creating an automated test runner for armhf_root_fs.tar.gz, ala
kvm-xfstests and gce-xfstests, but using the Android adb and fastboot
utilities to control the Android device, please let me know.  I'd love
to find a volunteer interested in working on this project!

   	  	    	       	  	     	  - Ted

Re: Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

On Thu, Jun 30, 2016 at 11:28:16AM -0400, Theodore Ts'o wrote:
> 
> Finally, it is now possible to build tar.gz file with all of the
> xfstests-bld test runner infrastructure using "./gen-image
> --out-tar=rootfs.tar.gz".  This can be used for those people who want
> to run xfstests on bare hardware without using KVM.  This also allows
> xfstests-bld to be built on a Debian armhf build server, and then
> create a tar.gz file that can be used to run a chroot environment on
> an Android device.

As I promised on the weekly ext4 conference call, I've made an
alpha-test release of these bits, which are available here:

https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/testing/

See the README.android for more details....

						- Ted

Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

There is an updated rootfs.img file available at:

    https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests

It includes the latest updates from the xfstests-dev upstream.  This
image also includes the dbench binary which enables generic/241.
There is also support for testing the virtio-rng kernel driver (not
for file system testing).

The gce-xfstests driver has been updated to support the latest gcloud
SDK and Debian releases.  For more information about this test
framework, please see:

    http://thunk.org/gce-xfstests

Finally, it is now possible to build tar.gz file with all of the
xfstests-bld test runner infrastructure using "./gen-image
--out-tar=rootfs.tar.gz".  This can be used for those people who want
to run xfstests on bare hardware without using KVM.  This also allows
xfstests-bld to be built on a Debian armhf build server, and then
create a tar.gz file that can be used to run a chroot environment on
an Android device.  (This requires using an external drive attached to
a USB C hub, with a special kernel which forces SELinux in Permissive
mode.  More documentation and automation will hopefully follow.)

Cheers,

						- Ted

Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

There is an updated rootfs.img file available at:

    https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests

It includes the latest updates from the xfstests-dev and quota
upstreams.  Some spurious test filaures in the encrypt and quota
configurations have been fixed.

In the gce-xfstests driver, we now also support DAX testing.  For more
information about this test framework, please see:

    http://thunk.org/gce-xfstests

Cheers,

						- Ted

Refreshed rootfs.img for kvm-xfstests

[Theodore Ts'o]

Hi, I've uploaded an updated rootfs.img at:

https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests

It includes the xfstests-dev upstream version 0e6ead559169 (Updated
from Oct. 14th) and some configuration changes to minimize some test
failure noise.  The config files are commented with the known
failures, for example:

https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/test-appliance/files/root/conf/encrypt.exclude

https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/test-appliance/files/root/conf/data_journal_noleak

I am currently getting the following results:

BEGIN TEST 4k: Ext4 4k block Sun Oct 25 07:29:52 EDT 2015
Failures: ext4/304
BEGIN TEST 1k: Ext4 1k block Sun Oct 25 08:12:58 EDT 2015
Failures: ext4/304 generic/018
BEGIN TEST ext3: Ext4 4k block emulating ext3 Sun Oct 25 09:01:21 EDT 2015
Failures: ext4/301 ext4/302 ext4/303 ext4/304 generic/018
BEGIN TEST encrypt: Ext4 encryption Sun Oct 25 09:44:13 EDT 2015
Failures: ext4/301 ext4/303 ext4/304
BEGIN TEST nojournal: Ext4 4k block w/ no journal Sun Oct 25 10:20:57 EDT 2015
Failures: ext4/301 ext4/304
BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Sun Oct 25 11:01:06 EDT 2015
Failures: ext4/304
BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Sun Oct 25 11:41:36 EDT 2015
Failures: ext4/001 ext4/304 ext4/308 generic/324
BEGIN TEST data_journal_noleak: Ext4 4k block w/data=journal Sun Oct 25 12:24:57 EDT 2015
Failures: ext4/271 ext4/301 ext4/302 ext4/303 ext4/304 ext4/308 generic/018
BEGIN TEST inline: Ext4 4k block w/inline Sun Oct 25 13:16:58 EDT 2015
Failures: ext4/304
BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Sun Oct 25 14:00:23 EDT 2015
Failures: ext4/004 generic/018 generic/204 generic/219 generic/235 generic/273
BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Sun Oct 25 14:46:29 EDT 2015
Failures: ext4/004 generic/018 generic/204 generic/235

(The ext4/30[1234] failures we only recently added back the these
tests that had been previously marked as dangerous and not in the auto
group.  ext4/304 is pretty clearly a buggy test as near as I can tell.
I haven't had a chance to rule out the others.  generic/018 is an
expected failures due to how we handle defrag; I should just add that
to all.exclude.  I need to take a closer look at some of the other
failures to understand what is going on.)

						- Ted