public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: xfs@oss.sgi.com
Subject: Some xfstests failures on non-crc xfs with latest xfsprogs (v4.5.0-rc1)
Date: Fri, 4 Mar 2016 19:23:54 +0800	[thread overview]
Message-ID: <20160304112354.GX11419@eguan.usersys.redhat.com> (raw)

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

Hi,

I noticed some xfstests failures while testing v4 XFS with latest
v4.5.0-rc1 xfsprogs on v4.5-rc6 kernel, and all these failures are gone
if I use v3.2.4 xfsprogs, or if test on v5 XFS.

So either xfstests needs update or xfsprogs breaks something for non-crc
XFS. But I'm not sure which is which, so I post them out for broader
review.

(All tests are checked with 'MKFS_OPTIONS="-m crc=0" ./check <sometest>')

== 1. xfs/032 fsck failure (xfs_db check) on ppc64 host ==

xfs/032 fails in the same way as the following steps on ppc64 host:

 mkfs -t xfs  -m crc=0 -s size=32768 -b size=65536 -d size=1g -f /dev/sda5
 xfs_db -c check /dev/sda5

This prints

 bad magic number 0 for inode 1792
 ...
 bad magic number 0 for inode 2047
 root inode 1792 is not a directory
 block 0/7 type unknown not expected
 allocated inode 1792 has 0 link count
 allocated inode 1793 has 0 link count
 allocated inode 1794 has 0 link count


== 2. xfs/033 fsck failure ==

xfs_repair detects more nlinks error. And this happens after commit
"c2c5096 libxfs: update to 3.16 kernel code"

# diff -u tests/xfs/033.out /root/xfstests/results//xfs_4k/xfs/033.out.bad
--- tests/xfs/033.out   2015-07-16 17:28:15.996000000 +0800
+++ /root/xfstests/results//xfs_4k/xfs/033.out.bad      2016-03-04 18:54:39.461000000 +0800
@@ -66,6 +66,7 @@
         - traversal finished ...
         - moving disconnected inodes to lost+found ...
 Phase 7 - verify and correct link counts...
+resetting inode INO nlinks from 0 to 1
 done
 Corrupting rt summary inode - setting bits to 0
 Wrote X.XXKb (value 0x0)
@@ -96,6 +97,7 @@
         - traversal finished ...
         - moving disconnected inodes to lost+found ...
 Phase 7 - verify and correct link counts...
+resetting inode INO nlinks from 0 to 1
 done
 Corrupting root inode - setting bits to -1
 Wrote X.XXKb (value 0xffffffff)
@@ -160,6 +162,7 @@
         - traversal finished ...
         - moving disconnected inodes to lost+found ...
 Phase 7 - verify and correct link counts...
+resetting inode INO nlinks from 0 to 1
 done
 Corrupting rt summary inode - setting bits to -1
 Wrote X.XXKb (value 0xffffffff)
@@ -191,4 +194,5 @@
         - traversal finished ...
         - moving disconnected inodes to lost+found ...
 Phase 7 - verify and correct link counts...
+resetting inode INO nlinks from 0 to 1
 done


== 3. xfs/108 xfs/196 xfs/261 xfs/244 fsck failure. ==

These tests fail in a similiar way, and they are all quota related.
Note that xfs/244 only fails on ppc64, others fail on all arches.

*** xfs_repair -n output ***
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 3
        - agno = 1
        - agno = 2
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 131, would move to lost+found
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
*** end xfs_repair outpu

== 4. xfs/186 xfs/187 attr test failure ==

xfs/186 is missing almost all the attr values.
xfs/187 reports test needs update.


Please see attachments for details.

Thanks,
Eryu

[-- Attachment #2: xfs-032-ppc64.full.bz2 --]
[-- Type: application/x-bzip2, Size: 4463 bytes --]

[-- Attachment #3: xfs-033.out.bad.bz2 --]
[-- Type: application/x-bzip2, Size: 1160 bytes --]

[-- Attachment #4: xfs-108.full.bz2 --]
[-- Type: application/x-bzip2, Size: 1580 bytes --]

[-- Attachment #5: xfs-186.out.bad.bz2 --]
[-- Type: application/x-bzip2, Size: 318 bytes --]

[-- Attachment #6: xfs-187.out.bad.bz2 --]
[-- Type: application/x-bzip2, Size: 198 bytes --]

[-- Attachment #7: xfs-196.full.bz2 --]
[-- Type: application/x-bzip2, Size: 1229 bytes --]

[-- Attachment #8: xfs-244-ppc64.full.bz2 --]
[-- Type: application/x-bzip2, Size: 1862 bytes --]

[-- Attachment #9: xfs-261.full.bz2 --]
[-- Type: application/x-bzip2, Size: 1183 bytes --]

[-- Attachment #10: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2016-03-04 11:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 11:23 Eryu Guan [this message]
2016-06-24 22:37 ` Some xfstests failures on non-crc xfs with latest xfsprogs (v4.5.0-rc1) Eric Sandeen
2016-06-25  4:44   ` Eryu Guan
2016-06-25  5:21     ` Eric Sandeen
2016-06-25  9:09       ` Eryu Guan

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=20160304112354.GX11419@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=xfs@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox