From: Brian Foster <bfoster@redhat.com>
To: Christian Kujau <christian@nerdbynature.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Metadata corruption detected at xfs_inode_buf_verify
Date: Mon, 17 Jul 2017 13:48:51 -0400 [thread overview]
Message-ID: <20170717174851.GB57771@bfoster.bfoster> (raw)
In-Reply-To: <alpine.DEB.2.21.1.1707170035440.22141@trent.utfs.org>
On Mon, Jul 17, 2017 at 12:47:16AM -0700, Christian Kujau wrote:
> On Sun, 16 Jul 2017, Christian Kujau wrote:
> > so, the disk enclosure attached to my RaspberryPi[0] had "some" kind of
> > failure last night: one of the disks appears to have some kind of hardware
> > problem, the other is fine, but the XFS file system cannot be mounted.
> > Instead of using the RPI to try the repair, I attached the enclosure to an
> > Intel i7 machine (16 GB RAM) and attempted to mount:
>
> After a late night chat on #xfs, it seems that the corruption may have
> happened due to a problem with the storage driver on this RPI and Dave
> commented:
>
> | and I'm pretty sure that the USB mass storage interface/driver does not
> | pass through cache flushes or support FUA operations.
> | which would explain why it appears that the inode cluster
> | initialisation IO isn't on disk, and it wasn't replayed by log recovery
> | before inode updates were recovered....
>
> (Put here so that it can be found in the archives, in case this happens to
> someone else)
>
> So, that being said, the now corrupted XFS still cannot be repaired by
> xfs_repair (compiled from a git checkout two days ago). The full
> xfs_repair run can be found the in screenlog:
>
> http://nerdbynature.de/bits/4.12.0-rc7/screenlog_1.txt
> The xfs_logprint and xfs_metadump outputs can be provided at request.
>
>
> Is this something xfs_repair should be able to fix or is the filesystem
> just too mangled in this case?
>
Hard to say for sure. I do wonder whether this is related to any of the
issues that Emmanuel ran into in his recent post[1]. Care to post the
metadump somewhere where it can be downloaded? Note that it usually can
be compressed to save upload/download time.
Brian
[1] http://www.spinics.net/lists/linux-xfs/msg08176.html
> Thanks,
> Christian.
> --
> BOFH excuse #431:
>
> Borg implants are failing
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-07-17 17:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-16 18:01 Metadata corruption detected at xfs_inode_buf_verify Christian Kujau
2017-07-17 7:47 ` Christian Kujau
2017-07-17 17:48 ` Brian Foster [this message]
2017-07-17 18:44 ` Christian Kujau
2017-07-19 6:54 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2017-04-06 0:36 Christian Kujau
2017-04-06 8:08 ` Carlos Maiolino
2017-04-06 17:50 ` Christian Kujau
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=20170717174851.GB57771@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=christian@nerdbynature.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox