XFS_REPAIR on LVM partition

Sun Dec 15 18:34:43 CST 2013

So, sadly I went for the big hammer option, I thought that there were no
other options ;).

I'm guessing it can't find or validate the primary superblock, so
> it's looking for a secondary superblock. Please post the output of
> the running repair so we can see exactly what it is doing.

That is exactly what it seems that it is happening.

*dmesg erros:*

>  81.927888] Pid: 878, comm: mount Not tainted 3.5.0-44-generic
> #67~precise1-Ubuntu
> [   81.927891] Call Trace:
> [   81.927941]  [<ffffffffa01d460f>] xfs_error_report+0x3f/0x50 [xfs]
> [   81.927972]  [<ffffffffa01ecd66>] ? xfs_free_extent+0xe6/0x130 [xfs]
> [   81.927990]  [<ffffffffa01ea318>] xfs_free_ag_extent+0x528/0x730 [xfs]
> [   81.928007]  [<ffffffffa01e8e07>] ? kmem_zone_alloc+0x67/0xe0 [xfs]
> [   81.928033]  [<ffffffffa01ecd66>] xfs_free_extent+0xe6/0x130 [xfs]
> [   81.928055]  [<ffffffffa021bb10>] xlog_recover_process_efi+0x170/0x1b0
> [xfs]
> [   81.928075]  [<ffffffffa021cd56>]
> xlog_recover_process_efis.isra.8+0x76/0xd0 [xfs]
> [   81.928097]  [<ffffffffa0220a17>] xlog_recover_finish+0x27/0xd0 [xfs]
> [   81.928119]  [<ffffffffa022812c>] xfs_log_mount_finish+0x2c/0x30 [xfs]
> [   81.928140]  [<ffffffffa0223620>] xfs_mountfs+0x420/0x6b0 [xfs]
> [   81.928156]  [<ffffffffa01e2ffd>] xfs_fs_fill_super+0x21d/0x2b0 [xfs]
> [   81.928163]  [<ffffffff8118b716>] mount_bdev+0x1c6/0x210
> [   81.928179]  [<ffffffffa01e2de0>] ? xfs_parseargs+0xb80/0xb80 [xfs]
> [   81.928194]  [<ffffffffa01e10a5>] xfs_fs_mount+0x15/0x20 [xfs]
> [   81.928198]  [<ffffffff8118c563>] mount_fs+0x43/0x1b0
> [   81.928202]  [<ffffffff811a5ee3>] ? find_filesystem+0x63/0x80
> [   81.928206]  [<ffffffff811a7246>] vfs_kern_mount+0x76/0x120
> [   81.928209]  [<ffffffff811a7c34>] do_kern_mount+0x54/0x110
> [   81.928212]  [<ffffffff811a9934>] do_mount+0x1a4/0x260
> [   81.928215]  [<ffffffff811a9e10>] sys_mount+0x90/0xe0
> [   81.928220]  [<ffffffff816a7729>] system_call_fastpath+0x16/0x1b
> [   81.928229] XFS (dm-0): Failed to recover EFIs
> [   81.928232] XFS (dm-0): log mount finish failed
> [   81.972741] XFS (dm-1): Mounting Filesystem
> [   82.195661] XFS (dm-1): Ending clean mount
> [   82.203627] XFS (dm-2): Mounting Filesystem
> [   82.479044] XFS (dm-2): Ending clean mount

Actually, the problem was a little bit more complicated. This LVM2
partition, was using a physical device (PV) that is exported by a RAID NAS
controller. This volume exported by the controller was created using a RAID
5, there was a hardware failure in one of the HDs of the array and the
volume got unavailable, till we replaced the bad driver with a new one and
the array rebuild finished.

That's an old version of xfsprogs - you might want to start by
> upgrading it to 3.11...
>
So, a good try should be upgrading to xfsprogs 3.11 and running xfs_repair
again.

2013/12/15 Dave Chinner <david at fromorbit.com>

> On Sun, Dec 15, 2013 at 08:47:30PM -0200, Rafael Weingartner wrote:
> > Hi folks,
> > I am having some troubles with a XFS over one LVM partition. After an
> > unexpected reboot, I am getting the following message when I try to mount
> > it:
> > *mount: Structure needs cleaning*
>
> And the error in dmesg is?
>
> > I tried "sudo xfs_check /dev/mapper/volume". Sadly, I got the message:
> > xfs_check: cannot init perag data (117)
>
> xfs_check is deprecated, please use "xfs_repair -n" instead.
>
> > *ERROR: The filesystem has valuable metadata changes in a log which needs
> > to*
> > *be replayed.  Mount the filesystem to replay the log, and unmount it
> > before*
> > *re-running xfs_check.  If you are unable to mount the filesystem, then
> use*
> > *the xfs_repair -L option to destroy the log and attempt a repair.*
> > *Note that destroying the log may cause corruption -- please attempt a
> > mount*
> > *of the filesystem before doing this*
> >
> > So, I tried:
> > xfs_repair -L
>
> Ok, so you went immediately for the big hammer. There's the
> possibility that might not be able to recover your filesystem from
> whatever went wrong now that the log has been zeroed.
>
> > The command is running for over 3 hours and still just dots on my
> screen, I
> > have no idea of what is happening. Any ideas how I can get it to work
> > again? Or at least some work around that would enable me to extract the
> > data that it contains.
>
> I'm guessing it can't find or validate the primary superblock, so
> it's looking for a secondary superblock. Please post the output of
> the running repair so we can see exactly what it is doing.
>
> Also we need more information about your problem - why did the
> machine reboot? what's your storage configuration? You hardware,
> etc.
>
>
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
>
> > The server is a Ubuntu server 12.04.
> > The XFS version is: xfs_info version 3.1.7
> > If you need I can provide you with more info.
>
> That's an old version of xfsprogs - you might want to start by
> upgrading it to 3.11...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david at fromorbit.com
>

-- 
Rafael Weingärtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20131215/400ab6d5/attachment-0001.html>