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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
