Failed Disk And Possible XFS Repair


clevoir

Recommended Posts

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

WP_20151101_12_25_27_Pro.jpg.5a9b20db3c4504bd0850fcedbd81ee4f.jpg

Link to comment

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

  • Thanks 1
Link to comment

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.

Link to comment

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!

Hopefuuly_OK_Now.jpg.b96d4ae39a73a98a4ec03593db3fd3a4.jpg

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.