On Nov 14, 2014, at 1:57 AM, Robert Tench <robtench@xxxxxxxxxxx> wrote:
> Robert has a file to share with you on OneDrive. To view it, click the link
> below.
> xfs.log
> So finally have managed to find a way to save the complete log of running
> xfs_repair -n /dev.md4
>
> And below is the output of xfs_check /dev/md4
>
> root@ubuntu:~# xfs_check /dev/md4
> * ERROR: mismatched uuid in log
> * SB : 813833a7-1bd3-4447-b575-09d1471bb652
> * log: ea3833af-25ce-9f91-b575-018fb49df3b1
> 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.
>
> And the output from mdadm -D /dev/md4 is as follows
>
> root@ubuntu:~# mdadm -D /dev/md4
> /dev/md4:
> Version : 1.0
> Creation Time : Fri Jan 1 01:31:17 2010
> Raid Level : raid5
> Array Size : 11712962560 (11170.35 GiB 11994.07 GB)
> Used Dev Size : 2928240640 (2792.59 GiB 2998.52 GB)
> Raid Devices : 5
> Total Devices : 5
> Persistence : Superblock is persistent
>
> Update Time : Fri Nov 14 15:58:16 2014
> State : clean
> Active Devices : 5
> Working Devices : 5
> Failed Devices : 0
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Name : (none):4
> UUID : e0829810:9782b51f:25529f65:8823419c
> Events : 1243386
>
> Number Major Minor RaidDevice State
> 0 8 2 0 active sync /dev/sda2
> 6 8 18 1 active sync /dev/sdb2
> 2 8 34 2 active sync /dev/sdc2
> 5 8 50 3 active sync /dev/sdd2
> 4 8 66 4 active sync /dev/sde2
>
>
> And then the response from mdadm -E /dev/md4
>
> root@ubuntu:~# mdadm -E /dev/md4
> mdadm: No md superblock detected on /dev/md4.
-D is for examining the logical md device, -E is for examining the individual
members so you’d use:
mdadm -E /dev/sd[abcde]2
Hopefully you haven’t used mdadm -C/—create ? The web is full of such
suggestions and it’s almost always the wrong thing to do, it’s a near last
resort in any case.
>
> Not sure what to do, any help would be appreciated
It’s very good to ask instead of haphazardly trying things. Trying to normally
mount the file system should be safe; and then use dmesg to check for kernel
messages. The xfs kernel code is responsible for log replay and making most
kinds of repairs, anything it can’t deal with will be reported as a kernel
message. If mount fails, report kernel xfs related messages, and also the
results from xfs_check -n.
Chris Murphy
|