I am running 6.1.3, and after running a scheduled Parity check overnight, I noticed this morning that Disk2 was showing Red.

 

I powered down the array, removed Disk 2 and run WD Diagnostics using a seperate PC, which showed read error and failed data blocks.

 

I have now installed a replacement disk into the Drive 2 postion, and the array is rebuilding

 

However on a monitor which I have attached to my Unraid array, a continous scrolling message is showing:-

 

XFS (md2) Metadata corruption detected at xfs _inode_but_verfify+0x8c/0xa6, block 0x74706dc0

XFS (md2) Unmount and run xfs repair

XFS (md2) First 64 butes of corrupted metadata buffer

 

A whole load of Hex numbers that I can't read as the screen is scrolling too fast

 

XFS (md2) : metadata I/O error: block 0x74706dc0 ("xfs_trans_read_buf_map") error 117 numblks 16

The data rebuild percentage is moving upwards, I assume that the array is rebuilding and carrying out an XFS repair. As such I guess I have to leave it running?

 

I have been running UnRaid since V3, and this is the first time that I have seen error messages where disks have been replaced / array rebuilt

 

See attached screenshot

No - a rebuild does not know what type of file system is in use.  You are probably going to have to run the xfs_repair to rectify this issue.  You can do it either after the rebuild completes, or stop the rebuild and do it against the emulated disk.

 

The process is:

• Stop array and restart in Maintenance mode
  
• From a console/telnet session run the commands

mkdir /mnt/tmp
mount /dev/md2 /mnt/tmp
umount /mnt/tmp
xfs_repair /dev/md2

It is possible that the xfs_repair step is not necessary if the issue has been completely fixed by the mount/umount sequence.  If you want you can add the -n parameter when running xfs_repair which will carry out a dummy run that actually makes no change to the disk if you want to see if xfs_repair thinks anything would need fixing.  There is also a -v parameter for verbose mode but I am not sure what extra output that gives.  If you do use the -n option then xfs_repair would need to be run again without that option to actually fix any errors found

I have complete this using xfs_repair but without the -n option

 

Pleaase see attached screenshot, as it looks like commands can't be found

That type of error should never happen.  It implies that there is something wrong with the OS level files in RAM.

 

Things that I can think of that might cause this:

• Borderline RAM.  Running a memory check could help with diagnosing such an issue
  
• Plugin that is loading incompatible libraries/files.  Starting unRAID in 'Safe' mode from the boot menu should stop plugins being started.
  
• Files being loaded via the /boot/extras folder that are incompatible.
  

Sorry I did not reboot into safe mode, only stopped the array and restarted in maintenance mode.

 

Is it worth repeating, booting in safe mode and then starting in maintenance mode?

I have rebooted in safe mode, and restarted in maintenace mode

 

I have run your same commands, and it appears that it has worked this time, see attached screenshot

 

I have then stopped the array restarted in normal mode, and the arry is rebuilding fine now with no messages on my monitor

 

So I guess Ive got a duff plug, now to find the one!

Sorry I forget to mention that I owe you a thank you for your help

 

I am a novice on XFS and couldn't have got there without your help