JJNBt

Ok, Ill get one as soon as can. Thank you for the help. Would I be able to labeled this post Solved?

Here is the Self SMART Extended Test, for the drive frsttower-smart-20201228-1546.zip

Sorry, that was not the Self SMART Extended Test. I will upload the once its done

I ran the extended SMART test, so attached is an updated diag. What would be the things that are in the Diag that show something is wrong? frsttower-diagnostics-20201228-1336.zip

Sorry for it being a little late. A little busy, also wanted to run a parity scan before I updated the Diags.

Attached is a updated diagnostics, Thank you. frsttower-diagnostics-20201227-0905.zip

Ok, I moved all of the SATA cables from the Marvell controllers, I also made a note of it on the case. I did grab one SMART from one of the disk that was disabled. In a few days I will add a new diags. Thank you for helping me CrystalDiskInfo_20201224181658.txt

ran xfs repair. -L "Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x46af5d, xfs_finobt block 0x16d74d588/0x1000 btree block 3/33851608 is suspect, error -74 bad magic # 0 in inobt block 3/33851608 agi_freecount 55, counted 0 in ag 3 finobt - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:16297) is ahead of log (1:2). Format log to cycle 4. done"

So one un mountable disk is currently disabled.

So I have 2 cables with 3 (4 pin molex.) One cable was powering 1.5 bays. I believe that was creating this issue, so now 2 cables are using 2 (4 pin molex) I wont be using the third molex from now on. I am currently rebuilding the drive if anyone can read the diagnostics file and can give me further information such as if any drive is failing because of potential power issues or something non related, would be great. Thank you

I just recently rebuild the array, it was working fine for a few weeks until last week we had a sudden black out I had to manually shut down the system luckily I decided to use and old UPS w/ new battery's and it worked fine for a few days. When the disk went down I had YouTube-DL, Krusader and Plex on. For some reason I was not able to shutdown Krusader before I had to force shutdown the system. I have two disk on the dashboard with error's thumbs down on the smart report. If you need further information I will reply your request asap. I also grabbed diagnostics before I shut down the computer and is attached. frsttower-diagnostics-20201220-1900.zip

I was able to get to work. here are my settings that worked. eth0 eth1 - I set ipv4 address assignment to automatic eth2- the 10GBE I gave it an IP of x.x.2.21 while the one on my windows pc is set to x.x.2.20

eth0 Bonding was ON turned it OFF. Change ip from x.x.x.20 to x.x.x.197 for eth1. Once I entered new ip to the new eth2 I notice on mac address it tells me that interface is shutdown (inactive.) So applied change. My server seems to still be active. Once I started the array I lost connection to unraid. just for fun I tried out x.x.x.197 ip, no luck

When looking at backup of unraid(so glad I did it) I notice that bonding members of bond0: eth0,eth2 and my bonding mode is at active backup (1). So I am changing ip of eth2 to x.x.x.197 since eth0 is x.x.x.199. I also change bond0: (to just) eth0. so those changes made my connection time out.

Ok so... When ever I set up my 10GBE, I seem to time out of my server. I connect to my system through eth1. after I did my parity process, I notice that I did not set my 10gbe with the ip x.x.x.20 I set up the other port that is on the motherboard with the ip x.x.x.20. So I turn off the parity once it was done and switched the information on the ports even the name eth2 clicked done and connection time out a few moments later. So I am stump can it be the 10gbe card which is a mellanox card is not supported or am I doing something wrong. A good thing I made a backup of my flash so most of my settings are ok hopefully i don't need to do another parity check.