All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-xfs@vger.kernel.org
Subject: [Bug 201823] New: inconsistent behaviour of xfs_db, xfs_repair and xfs_scrub
Date: Sat, 01 Dec 2018 08:16:13 +0000	[thread overview]
Message-ID: <bug-201823-201763@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=201823

            Bug ID: 201823
           Summary: inconsistent behaviour of xfs_db, xfs_repair and
                    xfs_scrub
           Product: File System
           Version: 2.5
    Kernel Version: 4.19.5
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: XFS
          Assignee: filesystem_xfs@kernel-bugs.kernel.org
          Reporter: matthias@bodenbinder.de
        Regression: No

Hi,

I am using xfs on Manjaro with kernel 4.19 and latest xfsprogs 4.19.0-1.

I checked my root filesystem with xfs_db for fragmentation and got metadata
corruption messages:

5# xfs_db -c frag -r /dev/sde1
Metadata corruption detected at 0x558ed74133f3, xfs_inode block 0x7faac0/0x8000
Metadata corruption detected at 0x558ed74133f3, xfs_inode block
0x20cb300/0x8000
Metadata corruption detected at 0x558ed74133f3, xfs_inode block
0x2341340/0x8000
aktuell 976616, ideal 970547, Unterteilungsfaktor 0,62%
Note, this number is largely meaningless.
Files on this filesystem average 1,01 extents per file

But xfs_repiar is not mentioning anything and hence not repairing anything.
Also, xfs_scrub is not complaining:

8# xfs_scrub -v /    
EXPERIMENTAL xfs_scrub program in use! Use at your own risk!
Phase 1: Find filesystem geometry.
/: using 8 threads to scrub.
Phase 2: Check internal metadata.
Phase 3: Scan all inodes.
Phase 5: Check directory tree.
Phase 7: Check summary counters.
41,6GiB data used;  1,3M inodes used.
41,5GiB data found; 1,3M inodes found.
1,3M inodes counted; 1,3M inodes checked.


How do I have to interpret these results? 
What can I do to get repair it?

I created an xfs dump just in case somebody wants to debug this.

Thank you for your help
Matthias

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2018-12-01 19:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-01  8:16 bugzilla-daemon [this message]
2018-12-01 19:13 ` [Bug 201823] inconsistent behaviour of xfs_db, xfs_repair and xfs_scrub bugzilla-daemon
2018-12-01 22:44 ` [Bug 201823] New: " Dave Chinner
2018-12-01 22:44 ` [Bug 201823] " bugzilla-daemon
2018-12-02  1:14 ` bugzilla-daemon
2018-12-02  8:27 ` bugzilla-daemon
2018-12-02 17:02 ` bugzilla-daemon
2018-12-02 17:28   ` Matthias Bodenbinder
2018-12-02 17:40 ` bugzilla-daemon
2018-12-03 21:21 ` bugzilla-daemon
2018-12-03 22:16 ` bugzilla-daemon
2018-12-03 22:35 ` bugzilla-daemon

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=bug-201823-201763@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-xfs@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.