I see an earlier thread about ext4 defrag problems causing this
failure on xfstest generic/018 running on ext4
generic/018 1s ... [failed, exit status 1] - output mismatch (see
/home/sfrench/xfstests/results//generic/018.out.bad)
--- tests/generic/018.out 2014-11-13 11:20:05.385406288 -0800
+++ /home/sfrench/xfstests/results//generic/018.out.bad 2014-11-13
12:33:19.317806287 -0800
@@ -10,10 +10,5 @@
After: 1
Write backwards sync, but contiguous - should defrag to 1 extent
Before: 10
-After: 1
-Write backwards sync leaving holes - defrag should do nothing
-Before: 16
-After: 16
...
but wasn't clear whether it was fixed upstream. It failed on two out
of three runs for me on most current ext4. My test is on most current
Ubuntu x86_64 (and with 3.18-rc3 kernel)
I couldn't find version info for e4defrag from the command line but
other ext4 tools are reasonably recent it seems as Ubuntu packages
them e.g. EXT2FS Library version 1.42.10, 18-May-2014
Is generic xfstest 18 still broken on ext4?
Also am curious about test generic/026
generic/026 [not run] ext4 does not define maximum ACL count
Is that expected?
--
Thanks,
Steve
On 11/13/14 3:16 PM, Steve French wrote:
> I see an earlier thread about ext4 defrag problems causing this
> failure on xfstest generic/018 running on ext4
>
> generic/018 1s ... [failed, exit status 1] - output mismatch (see
> /home/sfrench/xfstests/results//generic/018.out.bad)
> --- tests/generic/018.out 2014-11-13 11:20:05.385406288 -0800
> +++ /home/sfrench/xfstests/results//generic/018.out.bad 2014-11-13
> 12:33:19.317806287 -0800
> @@ -10,10 +10,5 @@
> After: 1
> Write backwards sync, but contiguous - should defrag to 1 extent
> Before: 10
> -After: 1
> -Write backwards sync leaving holes - defrag should do nothing
> -Before: 16
> -After: 16
> ...
>
> but wasn't clear whether it was fixed upstream. It failed on two out
> of three runs for me on most current ext4. My test is on most current
> Ubuntu x86_64 (and with 3.18-rc3 kernel)
> I couldn't find version info for e4defrag from the command line but
> other ext4 tools are reasonably recent it seems as Ubuntu packages
> them e.g. EXT2FS Library version 1.42.10, 18-May-2014
>
> Is generic xfstest 18 still broken on ext4?
Did you try upstream?
When I test upstream, it passes. Because:
# git log --oneline v1.42.10.. misc/e4defrag.c
c7c539e e4defrag: backwards-allocated files should be defragmented too
47fee2e e2fsprogs: introduce ext2fs_close_free() helper
So no, it is not still broken.
> Also am curious about test generic/026
>
> generic/026 [not run] ext4 does not define maximum ACL count
>
> Is that expected?
in common/attr:
# filesystems that want to test maximum supported acl counts need to
# add support in here
_acl_get_max()
...
Because ext4 has not added support there, yes, it is expected that it
will not run. ;)
I don't honestly know if ext4 has an upper limit on acls.
-Eric
On Thu, Nov 13, 2014 at 03:16:30PM -0600, Steve French wrote:
>
> Is generic xfstest 18 still broken on ext4?
Yes; the e4defrag program has different criteria for decided when to
defrag a file. I believe this should be fixed by commit c7c539e8fd86d
in e2fsprogs, but that's not yet in a released version yet.
> Also am curious about test generic/026
>
> generic/026 [not run] ext4 does not define maximum ACL count
>
> Is that expected?
Yes; the test currently is only wired up for jfs and xfs. (See
xfstests/common/attr:_acl_get_max).
- Ted
On Thu, Nov 13, 2014 at 03:36:13PM -0600, Eric Sandeen wrote:
>
> I don't honestly know if ext4 has an upper limit on acls.
The limit is based on the blocksize; but this test seems to assume an
absolute count of the number of acl entries, and looking at the xfs
max code, it looks like if we just wired it up to some arbitrary
number, such as "32", it would probably allow ext4 to run the test and
pass it correctly. I'm not sure it's would test something useful
that's not tested by the other xfstests, though.
- Ted
On Thu, Nov 13, 2014 at 05:04:55PM -0600, Steve French wrote:
> Only other xfstest I saw failing on ext4 on 3.18-rc3 was generic/315
> (Ubuntu 14.10).
>
> generic/315 [failed, exit status 1] - output mismatch (see
> /home/sfrench/xfstests/results//generic/315.out.bad)
> --- tests/generic/315.out 2014-11-13 11:20:05.405440282 -0800
> +++ /home/sfrench/xfstests/results//generic/315.out.bad 2014-11-13
> 13:34:57.346960909 -0800
> @@ -1,2 +1,6 @@
> QA output created by 315
> Slience is golden
> +ls: cannot access /mnt/test/testfile.315: No such file or directory
> +./tests/generic/315: line 69: [: : integer expression expected
> +File size is changed to ( Bytes)
> +(see /home/sfrench/xfstests/results//generic/315.full for details)
That test works just fine for me. The test is pretty simple; if the
file is not getting created, it sounds like problem with the fallocate
command. I'd suggest trying to run the commands in tests/generic/315
by hand, and seeing what's going wrong, but I'm pretty sure this is a
configuration issue in your test environment.
This is one of the reasons why I set up the xfstests-bld /
kvm-xfstests infrastructure, BTW; it handles most of these setup
issues for ext4 developers who otherwise might not end up using
xfstests for regression testing.
- Ted