Mismatch UUID
Chris Murphy
lists at colorremedies.com
Fri Nov 14 16:31:42 CST 2014
On Nov 14, 2014, at 1:57 AM, Robert Tench <robtench at hotmail.com> 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 at 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 at 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 at 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
More information about the xfs
mailing list