All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rhorer, Leslie" <Leslie.Rhorer@Level3.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: RE: xfs_repair fails
Date: Wed, 20 May 2015 02:41:03 +0000	[thread overview]
Message-ID: <D42CEF46A796364580AFE375880EF73F01AD645A5D@SRVMSXMBDEN2.ad.twtelecom.com> (raw)
In-Reply-To: <20150515121014.GA7099@bfoster.bfoster>

        Um, OK, it would definitely hang every time I attempt to mount the FS.  It didn't produce errors, it just sat there, and the process could not be killed.  Attempts to kill it would result in it attaching to the init process.  An attempted soft boot would hang after a mount attempt.  Per your suggestion, I cloned the git tree and compiled a new xfsprogs.  It worked!  I'm comparing to the backup system, and so far there are no unexpected failures.  I don't think I lost much, and nothing irreplaceable.

        Thanks a ton.

-----Original Message-----
From: Brian Foster [mailto:bfoster@redhat.com]
Sent: Friday, May 15, 2015 7:10 AM
To: Rhorer, Leslie
Cc: xfs@oss.sgi.com
Subject: Re: xfs_repair fails

On Fri, May 15, 2015 at 03:08:05AM +0000, Rhorer, Leslie wrote:
> kernel 3.16-2-amd64
> xfs_repair  3.2.1
> CPU cores 8
>
...
> Mount hangs if attempted
>

FWIW, I didn't reproduce a mount hang on my test vm running a variant of the 4.0 kernel.

> The XFS meta dump0 can be found at
> http://fletchergeek.com/images/metaxfs.gz
>
> RAID-Server:/var/log# xfs_repair -v /dev/md0 Phase 1 - find and verify
> superblock...
>         - reporting progress in intervals of 15 minutes
>         - block cache size set to 395032 entries Phase 2 - using
> internal log
>         - zero log...
> zero_log: head block 8 tail block 8
> ... <after a few minutes>
>         - scan filesystem freespace and inode maps...
> agi unlinked bucket 38 is 163000358 in ag 31 (inode=133306986534)
> zeroing unused portion of secondary superblock (AG #5) Segmentation
> fault

Thanks for all of the data and the metadump. I could reproduce with xfsprogs v3.2.2 but not with the very latest build out of my source tree. It looks like the crash is due to zeroing a 512 byte sized buffer based on a 4k sector size. This is already fixed in the following
commit:

        8bc43a39 repair: superblock buffers need to be sector sized

... which is available as of v3.2.3-rc1. I'm not sure what/whether packages might be available with that. You might need to grab the source to deal with this particular issue:

        https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/

With that fix, repair gets through and fixes whatever corruption it finds.

Brian

>
> -----Original Message-----
> From: Brian Foster [mailto:bfoster@redhat.com]
> Sent: Thursday, May 14, 2015 5:44 AM
> To: Rhorer, Leslie
> Cc: xfs@oss.sgi.com
> Subject: Re: xfs_repair fails
>
> On Thu, May 14, 2015 at 04:17:17AM +0000, Rhorer, Leslie wrote:
> > I have an XFS filesystem built on a 24T RAID6 Array under Debian Jessie Linux.  The kernel is 3.16-2-amd64, and the xfs_repair version is 3.2.1.  The file system has some inconsistencies, but every time I try to run xfs_repair, it segfaults.  What should I do?
> >
>
> Include as much information as you can about the filesystem, storage
> and
> problem:
>
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_
> when_reporting_a_problem.3F
>
> For a repair crash, the full output of the repair is a good start. Also, an xfs_metadump of the fs is probably the most effective tool to help us try and reproduce the problem, if you have somewhere you can post one.
>
> Brian
>
> >
> >
> > -------------
> >
> > The content contained in this electronic message is not intended to constitute formation of a contract binding Level3. Level3 will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone.
>
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
>
>
>
> -------------
>
>
>
> The content contained in this electronic message is not intended to constitute formation of a contract binding Level3. Level3 will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs


-------------



The content contained in this electronic message is not intended to constitute formation of a contract binding Level3. Level3 will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2015-05-20  2:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14  4:17 xfs_repair fails Rhorer, Leslie
2015-05-14 10:43 ` Brian Foster
2015-05-15  3:08   ` Rhorer, Leslie
2015-05-15 10:16     ` Emmanuel Florac
2015-05-15 12:10     ` Brian Foster
2015-05-20  2:41       ` Rhorer, Leslie [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=D42CEF46A796364580AFE375880EF73F01AD645A5D@SRVMSXMBDEN2.ad.twtelecom.com \
    --to=leslie.rhorer@level3.com \
    --cc=bfoster@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 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.