I'm currently using a docker MakeMKV to write cloned DVD structures in to a MKV container.  I've noticed that a share that I'm using for the output keeps dropping.  I can reboot and the array will start with all drives green and the share is restored.  A snippet from the log is attached.  I can start in maintenance mode and dry run xfs_repair on all the hard drives.  All are clean except md2.

 

Is it better to xfs_repair the md2 drive or replace with new drive and let it rebuild?  Note-while parity shows valid, it has been more than 700 days since last check.

 

Oct 13 18:36:15 Tower kernel: XFS (md2): Metadata CRC error detected at xfs_inobt_read_verify+0xd/0x3a [xfs], xfs_inobt block 0x19f754db8 
Oct 13 18:36:15 Tower kernel: XFS (md2): Unmount and run xfs_repair
Oct 13 18:36:15 Tower kernel: XFS (md2): First 128 bytes of corrupted metadata buffer:
Oct 13 18:36:15 Tower kernel: 0000000095cfb836: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 000000001de8c0f3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 00000000c8d99f19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 00000000a9a413e7: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 000000003c326670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 000000005abd08ab: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 000000003867ab1f: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: 0000000085cdd1ba: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Oct 13 18:36:15 Tower kernel: XFS (md2): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x19f754db8 len 8 error 74
Oct 13 18:36:15 Tower kernel: XFS (md2): xfs_do_force_shutdown(0x1) called from line 300 of file fs/xfs/xfs_trans_buf.c.  Return address = 000000007c1ff77b
Oct 13 18:36:15 Tower kernel: XFS (md2): I/O Error Detected. Shutting down filesystem
Oct 13 18:36:15 Tower kernel: XFS (md2): Please umount the filesystem and rectify the problem(s)

 

tower-diagnostics-20201013-2150.zip

Parity can't fix filesystem corruption, you need to run xfs_repair.

Thanks for your response. I had a feeling it would go that way. This is my first encounter with corruption.

When I complete the XFS repair it will prune data (according to the dry run output). Is that data lost for good or will unRaid recognize it and let parity reconstruct?


Sent from my iPhone using Tapatalk

Any partial/lost files will be moved to the lost+found folder, you can then analyze them, again parity can't help with filesystem corruption.