help on xfs test results

Hi Dave,

many thanks

Well, this is generic/256,
the expected output is null,
my output btw is full of failed and also non-failed operations. Sounds quite strange.

QA output created by 256
wrote 1073741824/1073741824 bytes at offset 0
1 GiB, 262144 ops; 0:01:58.00 (8.653 MiB/sec and 2215.1991 ops/sec)
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
pwrite64: No space left on device
/media/p6/fill/13.bin: No space left on device /media/p6/fill/14.bin: No space left on device /media/p6/fill/15.bin: No space left on device /media/p6/fill/16.bin: No space left on device /media/p6/fill/17.bin: No space left on device /media/p6/fill/18.bin: No space left on device /media/p6/fill/19.bin: No space left on device /media/p6/fill/20.bin: No space left on device
wrote 8192/8192 bytes at offset 0
8 KiB, 2 ops; 0.0000 sec (2.031 MiB/sec and 519.8856 ops/sec)
pwrite64: No space left on device
pwrite64: No space left on device
wrote 8192/8192 bytes at offset 0
8 KiB, 2 ops; 0.0000 sec (427.122 KiB/sec and 106.7806 ops/sec)
pwrite64: No space left on device
pwrite64: No space left on device
wrote 8192/8192 bytes at offset 0
8 KiB, 2 ops; 0.0000 sec (49.019 KiB/sec and 12.2548 ops/sec)
pwrite64: No space left on device
pwrite64: No space left on device
wrote 8192/8192 bytes at offset 0
.....

ack, thanks.

ack, thanks.

Sorry, was not precise in explaining this.
This is xfs/136,
Test is very long and full of differences compared to the expected .out. Strange thing is that the the messages are very similar, but values displayed are different.

xfs/136 - output mismatch (see
/home/angelo/xfstests/results//xfs/136.out.bad)

     --- tests/xfs/136.out	2015-09-17 10:54:06.984088997 +0000
     +++ /home/angelo/xfstests/results//xfs/136.out.bad	2015-09-20

# diff 136.out.bad ../../tests/xfs/136.out
17c17
< core.forkoff = 47 (376 bytes)
---

34c34
< core.forkoff = 47 (376 bytes)
---

57c57
< core.forkoff = 44 (352 bytes)
---

92c92
< core.forkoff = 37 (296 bytes)
---

150,250c150,153
< core.naextents = 0
< core.forkoff = 22 (176 bytes)
< core.aformat = 1 (local)
< a.sfattr.hdr.totsize = 235
< a.sfattr.hdr.count = 16
< a.sfattr.list[0].namelen = 6
< a.sfattr.list[0].valuelen = 5
< a.sfattr.list[0].root = 0
< a.sfattr.list[0].secure = 0
< a.sfattr.list[0].name = "name.1"
< a.sfattr.list[0].value = "value"
< a.sfattr.list[1].namelen = 6
< a.sfattr.list[1].valuelen = 5
< a.sfattr.list[1].root = 0
< a.sfattr.list[1].secure = 0
< a.sfattr.list[1].name = "name.2"
< a.sfattr.list[1].value = "value"
< a.sfattr.list[2].namelen = 6
< a.sfattr.list[2].valuelen = 5
< a.sfattr.list[2].root = 0
< a.sfattr.list[2].secure = 0
< a.sfattr.list[2].name = "name.3"
< a.sfattr.list[2].value = "value"
< a.sfattr.list[3].namelen = 6
< a.sfattr.list[3].valuelen = 5
< a.sfattr.list[3].root = 0
< a.sfattr.list[3].secure = 0
< a.sfattr.list[3].name = "name.4"
< a.sfattr.list[3].value = "value"
< a.sfattr.list[4].namelen = 6
< a.sfattr.list[4].valuelen = 5
< a.sfattr.list[4].root = 0
< a.sfattr.list[4].secure = 0
< a.sfattr.list[4].name = "name.5"
< a.sfattr.list[4].value = "value"
< a.sfattr.list[5].namelen = 6
< a.sfattr.list[5].valuelen = 5
< a.sfattr.list[5].root = 0
< a.sfattr.list[5].secure = 0
< a.sfattr.list[5].name = "name.6"
< a.sfattr.list[5].value = "value"
< a.sfattr.list[6].namelen = 6
< a.sfattr.list[6].valuelen = 5
< a.sfattr.list[6].root = 0
< a.sfattr.list[6].secure = 0
< a.sfattr.list[6].name = "name.7"
< a.sfattr.list[6].value = "value"
< a.sfattr.list[7].namelen = 6
< a.sfattr.list[7].valuelen = 5
< a.sfattr.list[7].root = 0
< a.sfattr.list[7].secure = 0
< a.sfattr.list[7].name = "name.8"
< a.sfattr.list[7].value = "value"
< a.sfattr.list[8].namelen = 6
< a.sfattr.list[8].valuelen = 5
< a.sfattr.list[8].root = 0
< a.sfattr.list[8].secure = 0
< a.sfattr.list[8].name = "name.9"
< a.sfattr.list[8].value = "value"
< a.sfattr.list[9].namelen = 7
< a.sfattr.list[9].valuelen = 5
< a.sfattr.list[9].root = 0
< a.sfattr.list[9].secure = 0
< a.sfattr.list[9].name = "name.10"
< a.sfattr.list[9].value = "value"
< a.sfattr.list[10].namelen = 7
< a.sfattr.list[10].valuelen = 5
< a.sfattr.list[10].root = 0
< a.sfattr.list[10].secure = 0
< a.sfattr.list[10].name = "name.11"
< a.sfattr.list[10].value = "value"
< a.sfattr.list[11].namelen = 7
< a.sfattr.list[11].valuelen = 5
< a.sfattr.list[11].root = 0
< a.sfattr.list[11].secure = 0
< a.sfattr.list[11].name = "name.12"
< a.sfattr.list[11].value = "value"
< a.sfattr.list[12].namelen = 7
< a.sfattr.list[12].valuelen = 5
< a.sfattr.list[12].root = 0
< a.sfattr.list[12].secure = 0
< a.sfattr.list[12].name = "name.13"
< a.sfattr.list[12].value = "value"
< a.sfattr.list[13].namelen = 7
< a.sfattr.list[13].valuelen = 5
< a.sfattr.list[13].root = 0
< a.sfattr.list[13].secure = 0
< a.sfattr.list[13].name = "name.14"
< a.sfattr.list[13].value = "value"
< a.sfattr.list[14].namelen = 7
< a.sfattr.list[14].valuelen = 5
< a.sfattr.list[14].root = 0
< a.sfattr.list[14].secure = 0
< a.sfattr.list[14].name = "name.15"
< a.sfattr.list[14].value = "value"
< a.sfattr.list[15].namelen = 7
< a.sfattr.list[15].valuelen = 5
< a.sfattr.list[15].root = 0
< a.sfattr.list[15].secure = 0
< a.sfattr.list[15].name = "name.16"
< a.sfattr.list[15].value = "value"
---

.....

Regards,
Angelo

It uses "&> /dev/null" as the method of redirection. what happens if you replace that with something like "> /dev/null 2>&1"?

....

Ah, xfs/136 is not part of the "auto" group. That means it's unreliable. Indeed, the original commit back in 2006:

commit 7dcf3ce6f95603965b51c53d0a48864b0c6e8268

Author: Tim Shimmin <[email protected]>
Date:   Tue Oct 17 06:10:19 2006 +0000

test out attr2 with different number of extents and number of EAs - with both sizes shrinking and enlarging and changing formats. Need to fix up the output before setting live. Merge of master-melb:xfs-cmds:27208a by kenmcd.

had output problems and it has never been fixed...

And, looking at:

commit 3e29b0b732f2386aa01e1b8d6dc3e57bfe6d3762

Author: Tim Shimmin <[email protected]>
Date:   Fri Dec 1 14:46:42 2006 +0000

Add some more tests for the attr2 test.
Do some EA and extent interaction at different formats due to different number of extents and EAs.
It showed up the current attr2 bug.
With the proposed patch this doesn't happen.
Merge of master-melb:xfs-cmds:27606a by kenmcd.

The diff has:

-- a/136.out
+++ b/136.out
@@ -22,7 +22,7 @@ core.size = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
-core.forkoff = 47 (376 bytes)
+core.forkoff = 24 (192 bytes)
core.aformat = 1 (local)
a.sfattr.hdr.totsize = 18
a.sfattr.hdr.count = 1
@@ -39,7 +39,7 @@ core.size = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
-core.forkoff = 47 (376 bytes)
+core.forkoff = 24 (192 bytes)
core.aformat = 1 (local)
a.sfattr.hdr.totsize = 32
a.sfattr.hdr.count = 2
@@ -62,7 +62,7 @@ core.size = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
-core.forkoff = 44 (352 bytes)
+core.forkoff = 24 (192 bytes)
core.aformat = 1 (local)
a.sfattr.hdr.totsize = 60
a.sfattr.hdr.count = 4
@@ -97,7 +97,7 @@ core.size = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
-core.forkoff = 37 (296 bytes)
+core.forkoff = 24 (192 bytes)
core.aformat = 1 (local)
a.sfattr.hdr.totsize = 116
a.sfattr.hdr.count = 8

Which looks very much like the diff you are seeing, and I think the bug referred to by the commit message was fixed by this commit:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff;h=94aa0de19b6654848be060d4bcae2e9147733d41

which implies the attribute fork is being created with the wrong size. Hmmm.

Are you testing with something like selinux or some other security subsystem enabled that creates attributes at inode creation time?

Also, can you run this:

$ pahole fs/xfs/libxfs/xfs_attr.o

And grab the output of these structure definitions:

(from x86-64, using gcc 4.9.3):

struct xfs_attr_sf_hdr {
        __be16                     totsize;              /*     0     2 */
        __u8                       count;                /*     2     1 */

        /* size: 4, cachelines: 1, members: 2 */
        /* padding: 1 */
        /* last cacheline: 4 bytes */
};
struct xfs_attr_sf_entry {
        __uint8_t                  namelen;              /*     0     1 */
        __uint8_t                  valuelen;             /*     1     1 */
        __uint8_t                  flags;                /*     2     1 */
        __uint8_t                  nameval[1];           /*     3     1 */

        /* size: 4, cachelines: 1, members: 4 */
        /* last cacheline: 4 bytes */
};
struct xfs_attr_shortform {
        struct xfs_attr_sf_hdr     hdr;                  /*     0     4 */

        /* XXX last struct has 1 byte of padding */

        struct xfs_attr_sf_entry   list[1];              /*     4     4 */

        /* size: 8, cachelines: 1, members: 2 */
        /* paddings: 1, sum paddings: 1 */
        /* last cacheline: 8 bytes */
};

Cheers,

Dave.

Dave Chinner
[email protected]

In theory, xfstests detects this and mounts with an fs-wide context to avoid that...

-Eric

For selinux, yes. i don't think it's aware of anything else, though...

Cheers,

Dave.

Dave Chinner
[email protected]

Hi Dave, Eric and all,

still thanks.

About generic/256 failing in my system,

in the xfstests README there is:

- create fsgqa test user ("sudo useradd fsgqa")

this creates the user, but in /etc/passwd comes "/bin/sh" as shell, and in this system is it "dash". Redirection to /dev/null as required from this test then fails. Setting to "/bin/bash" test passes.

About xfs/136,

ack, thanks.

Best regards
Angelo