From: "Dai, XiangX" <xiangx.dai@intel.com>
To: fstests@vger.kernel.org
Subject: generic/482: always failed with xfs
Date: Fri, 31 Aug 2018 16:40:59 +0800 [thread overview]
Message-ID: <d0a6d7b6-12dd-14eb-07d9-2ff28cb2af52@intel.com> (raw)
generic/482 is unstable when we run it with xfs (it runs well with other
fs type)
run 10 times, failed 6 times
------
generic/482 [failed, exit status 1]- output mismatch (see
/lkp/benchmarks/xfstests/results//generic/482.out.bad)
--- tests/generic/482.out 2018-07-09 10:39:04.000000000 +0000
+++ /lkp/benchmarks/xfstests/results//generic/482.out.bad
2018-08-16 14:38:22.306000000 +0000
@@ -1,2 +1,3 @@
QA output created by 482
-Silence is golden
+_check_xfs_filesystem: filesystem on /dev/vdd is inconsistent (r)
+(see /lkp/benchmarks/xfstests/results//generic/482.full for details)
...
(Run 'diff -u tests/generic/482.out
/lkp/benchmarks/xfstests/results//generic/482.out.bad' to see the
entire diff)
------
482.full
------
# ./ltp/fsstress -w -d /fs/scratch -n 512 -p 4
seed = 1534216816
mark mkfs has entry number 624
next fua is entry number 674
=== replay to 674 ===
_check_xfs_filesystem: filesystem on /dev/vdd is inconsistent (r)
*** 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
bad symlink header ino 268697729, file block 0, disk block 33587215
problem with symbolic link in inode 268697729
would have cleared inode 268697729
- 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 = 1
- agno = 2
entry "l6" in shortform directory 268697728 references free inode 268697729
would have junked entry "l6" in directory inode 268697728
- agno = 3
bad symlink header ino 268697729, file block 0, disk block 33587215
problem with symbolic link in inode 268697729
would have cleared inode 268697729
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
entry "l6" in shortform directory inode 268697728 points to free inode
268697729
would junk entry
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
Maximum metadata LSN (1:338) is ahead of log (1:41).
Would format log to cycle 4.
No modify flag set, skipping filesystem flush and exiting.
*** end xfs_repair output
*** mount output ***
rootfs on / type rootfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=1776968k,nr_inodes=444242,mode=755)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/rdma type cgroup
(rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpu type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup
(rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup
(rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1500)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmp on /tmp type tmpfs (rw,relatime)
inn:/result on /inn/result type nfs
(rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.1,mountvers=3,mountport=32955,mountproto=udp,local_lock=none,addr=192.168.1.1)
*** end mount output
device-mapper: remove ioctl on logwrites-test failed: No such device or
address
Command failed
------
next reply other threads:[~2018-08-31 12:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 8:40 Dai, XiangX [this message]
2018-08-31 12:34 ` generic/482: always failed with xfs 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=d0a6d7b6-12dd-14eb-07d9-2ff28cb2af52@intel.com \
--to=xiangx.dai@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox