|To:||Dave Chinner <david@xxxxxxxxxxxxx>, Sean Caron <scaron@xxxxxxxxx>|
|Subject:||Re: What to do when... xfs_repair hangs?|
|From:||Sean Caron <scaron@xxxxxxxxx>|
|Date:||Sun, 1 Jun 2014 12:21:55 -0400|
Sorry, all, I was a little out-of-it on Friday afternoon, of course I had kicked off xfs_repair actually in the background with all output sent to a file, and I was just doing 'tail -f' on that file.
So I kill the 'tail -f' and jump back to the command line, it appears that xfs_repair segfaulted and died.
That line of text:
disconnected inode 1109099673,
was indeed the last thing that it printed before it crashed.
If I look in dmesg, I just see -
xfs_repair: segfault at 28 ip 000000000042307b sp 00007fffef61bad0 error 4 in xfs_repair[400000+72000]
and that's it.
I checked with 'df' and there's plenty of space everywhere; I don't see why it would have faulted out trying to connect something to lost+found.
Underlying storage should be good; this is basically a RAID 60 built on top of a bunch of JBODs with LSI SAS9200 cards. MD sees all strings as started and running OK; no problems getting the array assembled at all.
Since Dave is saying it's OK to try re-running xfs_repair; it'll just pick up where it left off; let me give it another pass and see if it manages to complete, or if it segfaults out again. I guess it it poops out a second time, maybe we'll just want to consider rebuilding the filesystem and restoring from our copies?
Thanks for the feedback,
On Fri, May 30, 2014 at 8:01 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
|<Prev in Thread]||Current Thread||[Next in Thread>|