help on xfs test results

help on xfs test results

[Angelo Dureghello]

Hi all,

thanks for all the great support until now.

I finally completed all the tests in my arm 32 bit target platform, and 
have still 4 hopefully false positives. Below my comments:



generic tests

*** 256
/media/p6/fill.161/3.bin: No space left on device

  - output mismatch (see 
/home/angelo/xfstests/results//./generic/256.out.bad)
     --- tests/./generic/256.out	2015-09-17 10:54:06.815078834 +0000
     +++ /home/angelo/xfstests/results//./generic/256.out.bad	2000-01-01 
00:42:13.822058816 +0000
     @@ -1 +1,2229 @@
      QA output created by 256
     +wrote 1073741824/1073741824 bytes at offset 0
     +1 GiB, 262144 ops; 0:02:35.00 (6.602 MiB/sec and 1690.0353 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
     ...


xfs tests
**** 020
creates a 60t, fails if > 16t (Growing the data section failed), could 
be normal in 32bit arch ?

**** 080
Looks like not XFS issue. mmap() failed, no more memory after 2,5G

# ./start_xfs_test.sh
QA output created by 080
[ 5263.189727] XFS (mmcblk0p5): Mounting V4 Filesystem
[ 5263.459360] XFS (mmcblk0p5): Ending clean mount

mmappiong 512000000
mmappiong 512000000
mmappiong 512000000

doio (31296) 01:27:38
---------------------
mmap() failed - 0xffffffff 12

doio (31296) 01:27:38
---------------------
mmap-write() request failed:  Cannot allocate memory (12)
Request number 59
           fd 11 is file /media/p5/rwtest.file - open flags are 0200002 
O_RDWR,O_DIRECT,
           write done at file offset 4178432 - pattern is M (0115)
           number of requests is 1, strides per request is 1
           i/o byte count = 56832
           memory alignment is aligned
           DIRECT I/O: offset % 512 = 0 length % 56832 = 0
           mem alignment 0x200 xfer size: small: 512 large: 2147483136

syscall:  mmap-write(NULL, 512000000, PROT_WRITE, MAP_SHARED, 11, 0)
	file is mmaped to: 0x0
	file-mem=0x3fc200, length=56832, buffer=0x48600


doio (31296) 01:27:38
---------------------
doio(): operation 121 returned != 0
rwtest.sh : iogen reported errors (r=141)


**** 136
very long test, output similar but different values


Hope those finding can be useful, and maybe some of you have an
idea on the reasons. I am still investigating.


Many thanks,
Regards,
Angelo Dureghello


-------------------------------------------------------------------------

Below info on the target system.

# cat /proc/version
Linux version 4.1.6-rt5+ (angelo@hostpc) (gcc version 4.9.3 20150413 
(prerelease) (Linaro GCC 4.9-2015.05) ) #118 SMP PREEMPT RT Tue Sep 29 
13:31:25 CEST 2015

Linux host 4.1.6-rt5+ #118 SMP PREEMPT RT Tue Sep 29 13:31:25 CEST 2015 
armv7l GNU/Linux

Using microsd for kernel, rootfs, test partitions, and setting:

export TEST_DEV='/dev/mmcblk0p5'
export TEST_DIR='/media/p5'
export SCRATCH_DEV='/dev/mmcblk0p6'
export SCRATCH_MNT='/media/p6'
export FSTYP='xfs'

Re: help on xfs test results

[Dave Chinner]

On Wed, Sep 30, 2015 at 01:03:36AM +0200, Angelo Dureghello wrote:
> Hi all,
> 
> thanks for all the great support until now.
> 
> I finally completed all the tests in my arm 32 bit target platform,
> and have still 4 hopefully false positives. Below my comments:
> 
> 
> 
> generic tests
> 
> *** 256
> /media/p6/fill.161/3.bin: No space left on device
> 
>  - output mismatch (see
> /home/angelo/xfstests/results//./generic/256.out.bad)
>     --- tests/./generic/256.out	2015-09-17 10:54:06.815078834 +0000
>     +++
> /home/angelo/xfstests/results//./generic/256.out.bad	2000-01-01
> 00:42:13.822058816 +0000
>     @@ -1 +1,2229 @@
>      QA output created by 256
>     +wrote 1073741824/1073741824 bytes at offset 0
>     +1 GiB, 262144 ops; 0:02:35.00 (6.602 MiB/sec and 1690.0353 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
>     ...

There should be ENOSPC being reported during the test but they
should all be redirected to /dev/null. Perhaps shomething wrong with
redirection?

> xfs tests
> **** 020

You need to be more explicit about the test description. Does "020"
mean generic/020, xfs/020, btrfs/020, etc?

> creates a 60t, fails if > 16t (Growing the data section failed),
> could be normal in 32bit arch ?

32 bit system can't use a 60TB block device or file, so this needs
a "_requires_64bit_blockdev" type of check.

> **** 080
> Looks like not XFS issue. mmap() failed, no more memory after 2,5G

various tests will fail if you don't have enough memory or address
space. Expunge them from your normal testing if it's just memory
allocation that is the problem.

> **** 136
> very long test, output similar but different values

xfs/136 shouldn't run your machine out of memory. If it does, then
you probably should start looking for a memory leak...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: help on xfs test results

[Angelo Dureghello]

Hi Dave,

many thanks

On 30/09/2015 01:28, Dave Chinner wrote:
> On Wed, Sep 30, 2015 at 01:03:36AM +0200, Angelo Dureghello wrote:
>> Hi all,
>>
>> thanks for all the great support until now.
>>
>> I finally completed all the tests in my arm 32 bit target platform,
>> and have still 4 hopefully false positives. Below my comments:
>>
>>
>>
>> generic tests
>>
>> *** 256
>> /media/p6/fill.161/3.bin: No space left on device
>>
>>   - output mismatch (see
>> /home/angelo/xfstests/results//./generic/256.out.bad)
>>      --- tests/./generic/256.out	2015-09-17 10:54:06.815078834 +0000
>>      +++
>> /home/angelo/xfstests/results//./generic/256.out.bad	2000-01-01
>> 00:42:13.822058816 +0000
>>      @@ -1 +1,2229 @@
>>       QA output created by 256
>>      +wrote 1073741824/1073741824 bytes at offset 0
>>      +1 GiB, 262144 ops; 0:02:35.00 (6.602 MiB/sec and 1690.0353 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
>>      ...
>
> There should be ENOSPC being reported during the test but they
> should all be redirected to /dev/null. Perhaps shomething wrong with
> redirection?

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
.....



>
>> xfs tests
>> **** 020
>
> You need to be more explicit about the test description. Does "020"
> mean generic/020, xfs/020, btrfs/020, etc?
>
>> creates a 60t, fails if > 16t (Growing the data section failed),
>> could be normal in 32bit arch ?
>
> 32 bit system can't use a 60TB block device or file, so this needs
> a "_requires_64bit_blockdev" type of check.
>

ack, thanks.

>> **** 080
>> Looks like not XFS issue. mmap() failed, no more memory after 2,5G
>
> various tests will fail if you don't have enough memory or address
> space. Expunge them from your normal testing if it's just memory
> allocation that is the problem.

ack, thanks.


>
>> **** 136
>> very long test, output similar but different values
>
> xfs/136 shouldn't run your machine out of memory. If it does, then
> you probably should start looking for a memory leak...
>

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)
---
 > core.forkoff = 24 (192 bytes)
34c34
< core.forkoff = 47 (376 bytes)
---
 > core.forkoff = 24 (192 bytes)
57c57
< core.forkoff = 44 (352 bytes)
---
 > core.forkoff = 24 (192 bytes)
92c92
< core.forkoff = 37 (296 bytes)
---
 > core.forkoff = 24 (192 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"
---
 > core.naextents = 1
 > core.forkoff = 24 (192 bytes)
 > core.aformat = 2 (extents)
 > a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,16,1,0]
.....




Regards,
Angelo

Re: help on xfs test results

[Dave Chinner]

On Thu, Oct 01, 2015 at 10:48:21AM +0200, Angelo Dureghello wrote:
> On 30/09/2015 01:28, Dave Chinner wrote:
> >On Wed, Sep 30, 2015 at 01:03:36AM +0200, Angelo Dureghello wrote:
> >>00:42:13.822058816 +0000
> >>     @@ -1 +1,2229 @@
> >>      QA output created by 256
> >>     +wrote 1073741824/1073741824 bytes at offset 0
> >>     +1 GiB, 262144 ops; 0:02:35.00 (6.602 MiB/sec and 1690.0353 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
> >>     ...
> >
> >There should be ENOSPC being reported during the test but they
> >should all be redirected to /dev/null. Perhaps shomething wrong with
> >redirection?
> 
> 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.

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

....

> >>**** 136
> >>very long test, output similar but different values
> >
> >xfs/136 shouldn't run your machine out of memory. If it does, then
> >you probably should start looking for a memory leak...
> >
> 
> 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
> 

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 <tes@sgi.com>
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 <tes@sgi.com>
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
david@fromorbit.com

Re: help on xfs test results

[Eric Sandeen]

On 10/1/15 6:56 PM, Dave Chinner wrote:
> Are you testing with something like selinux or some other security
> subsystem enabled that creates attributes at inode creation time?

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

-Eric

Re: help on xfs test results

[Dave Chinner]

On Thu, Oct 01, 2015 at 07:31:13PM -0500, Eric Sandeen wrote:
> 
> 
> On 10/1/15 6:56 PM, Dave Chinner wrote:
> > Are you testing with something like selinux or some other security
> > subsystem enabled that creates attributes at inode creation time?
> 
> In theory, xfstests detects this and mounts with an fs-wide context
> to avoid that...

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

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: help on xfs test results

[Angelo Dureghello]

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.



On 02/10/2015 02:38, Dave Chinner wrote:
> On Thu, Oct 01, 2015 at 07:31:13PM -0500, Eric Sandeen wrote:
>>
>>
>> On 10/1/15 6:56 PM, Dave Chinner wrote:
>>> Are you testing with something like selinux or some other security
>>> subsystem enabled that creates attributes at inode creation time?
>>
>> In theory, xfstests detects this and mounts with an fs-wide context
>> to avoid that...
>
> For selinux, yes. i don't think it's aware of anything else,
> though...
>
> Cheers,
>
> Dave.
>


Best regards
Angelo