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