All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <guaneryu@gmail.com>
To: "Dai, XiangX" <xiangx.dai@intel.com>
Cc: fstests@vger.kernel.org
Subject: Re: generic/482: always failed with xfs
Date: Fri, 31 Aug 2018 20:34:28 +0800	[thread overview]
Message-ID: <20180831123415.GE3651@desktop> (raw)
In-Reply-To: <d0a6d7b6-12dd-14eb-07d9-2ff28cb2af52@intel.com>

On Fri, Aug 31, 2018 at 04:40:59PM +0800, Dai, XiangX wrote:
> 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).

Yeah, it's known to fail on xfs since the test was merged. Dave
suspected it was a bug in log-dev[1], but there's no conclusion yet ..

Thanks,
Eryu

[1] https://patchwork.kernel.org/patch/10312149/#21674087

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

      reply	other threads:[~2018-08-31 16:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31  8:40 generic/482: always failed with xfs Dai, XiangX
2018-08-31 12:34 ` Eryu Guan [this message]

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=20180831123415.GE3651@desktop \
    --to=guaneryu@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=xiangx.dai@intel.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 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.