xfs
[Top] [All Lists]

Re: Mismatch UUID

To: Robert Tench <robtench@xxxxxxxxxxx>
Subject: Re: Mismatch UUID
From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
Date: Fri, 14 Nov 2014 15:31:42 -0700
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <BLU172-W9B4FE524F07D7E6D5592BC48C0@xxxxxxx>
References: <BLU172-W9B4FE524F07D7E6D5592BC48C0@xxxxxxx>
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
<Prev in Thread] Current Thread [Next in Thread>