All of lore.kernel.org
 help / color / mirror / Atom feed
From: Angelo Dureghello <angelo@sysam.it>
To: fstests <fstests@vger.kernel.org>
Subject: Re: help on xfs test results
Date: Thu, 01 Oct 2015 10:48:21 +0200	[thread overview]
Message-ID: <560CF355.7050200@sysam.it> (raw)
In-Reply-To: <560C69D9.6020807@sysam.it>

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





       reply	other threads:[~2015-10-01  8:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <560C69D9.6020807@sysam.it>
2015-10-01  8:48 ` Angelo Dureghello [this message]
2015-10-01 23:56   ` help on xfs test results Dave Chinner
2015-10-02  0:31     ` Eric Sandeen
2015-10-02  0:38       ` Dave Chinner
2015-10-05 17:15         ` Angelo Dureghello
2015-09-29 23:03 Angelo Dureghello
2015-09-29 23:28 ` Dave Chinner

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=560CF355.7050200@sysam.it \
    --to=angelo@sysam.it \
    --cc=fstests@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.