mathomas3

When you say that the SAS disks have been disconnected and reconnected as different devices... what do you mean? I didnt reassign the disks when everything was moved into the new box.

I do have a UPS. Though I need to get a larger one, Im pushing this current one on what it can handle. For power I connected 1 PSU to the UPS and the second PSU directly to the wall. Im thinking what happened is that the DAS lost power for 0.01 of a second causing the errors on the disks and since Parity and disk 8 were actively being accessed they got disabled.

Negative. Smart reports look good for the ones I have looked at.

correct. All of the drives are connected via the RAID controller When I moved everything over I had to use a different RAID controller(thought I was using a recommended one from the unraid wiki) If I recall disks 9-11 are SAS and all the rest are SATA drives

Oh and after posting the most recent Diags I disabled docker to limit writes to the array. Dont think that should effect anything, but I figure it's for the best

Before I forget to mention it. Thank you for the quick assistance. It's been a while since I have had drive failures, but never had more then one die at a time. I did recently move UNRaid into this hardware, an HP 1u Server and a 24bay DAS, both with dual PSUs. Hasn't given me any issues up till now.

faster read times while also having the data protected is what I was aiming for... though I have been considering moving it out of the array for sometime now

tower-diagnostics-20220729-1423.zip Rebooted and posting Diags. Those two disks are still red balled... funny thing is though that disk 8 is a 2 month old ssd...

As a sysadmin... that's something you tell users all the time but not something you ever want to be told yourself 🤔

Also there is this error... Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md11, logical block 1953506608, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522944, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522945, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522946, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522947, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522948, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522949, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522950, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md8, logical block 1953522951, async page read Jul 29 12:10:01 Tower kernel: Buffer I/O error on dev md6, logical block 1953506608, async page read Jul 29 12:10:01 Tower kernel: blk_update_request: I/O error, dev loop2, sector 41942912 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Hello all, I think I had a little power flick or something, but I noticed that my server's fans starting spinning a little bit quicker for a second which prompted me to check the server. After pulling up the page disk 8 is red balled and all ther other disks have 300-400ish errors. Wanting to prevent further errors I tried to stop the array and that's where it's stuck. ' lsof | grep /mnt lsof: WARNING: can't stat() xfs file system /mnt/disk8 Output information may be incomplete. ' Before any of this happened I suspected that disk 10 was on the way out due to 114 read errors that happened yesterday, though an extended SMART diag came back good... And now the parity drive is red balled... HELP! tower-diagnostics-20220729-1405.zip

I currently run 8tb drives... and from the start I have always used fill-up with 100gb min free space... it's been working well for me... just to give you an example

After reseating the card validating everything was plugged in... it still didnt work... unless someone knows about how these cards work... perhaps it requires a monitor to be connected at start? The card I bought was from dell at T400 at this point I think it's a dead card... thoughts?

In looking into the IOMMU groups... unless im mistaken... I am not seeing the T400... sure sure how that is possible... ill double check the hardware physically...

Hello @ich777 I just got in the T400 and plugged it in... Problem is that we have driver issues again... I did confirm that the 515.57 drivers should be used via NVIDIA support page tower-diagnostics-20220702-1555.zip

That and also I would run it without your VMs being powered on... Default bios settings and Unraid (without VMs) Run it like this for a day or so. In order to get MacOS to run on this hardware, I would assume that you had to make a number of modifications to get it to run, could you explain what changes those might have been

As a first thing that I would do... reset the bios to factory settings... this feels like a power save setting of sorts... When the system does become unresponsive have tried to access the console physically?

What is this 'server'?? you have 2 500gb m.2 drives attached... This is a gaming rig more then anything... If you are using unraid as the host OS... why?

I think I followed this parity/data swap guide that Jona is talking about years ago... and it worked at the time... but again that was a long time ago when I was using 6tb drives

Diags for me takes a few minutes... depending on the logs and the number of drives and dockers/plugins... that number will vary... but please give them a chance to complete...

Reading the notes of the guide... You are Correct! (even after using this software for nearly 10 years... I still have much to learn) So OP... Please lean to Jona's suggestion with the swap guide... As a side question Jona... would it be possible for OP to build a second parity drive(using the 8tb drive) and then rebuild the failed data drive with a 8tb one?

While this could work... wouldn't the safest way forward be replacing the failed drive first and then replacing the parity drive? While this guide suggest 2 steps in one... doing each step separately be the safer option?

IMO follow this guide first... and then do the parity swap... https://wiki.unraid.net/Replacing_a_Data_Drive to put things simply... shut down the array... replace the failed drive... power on the machine... stop the array... select the new data drive in place of the failed drive... start the array... this will rebuild the failed drive(this will take around 12h or more)... after that's done... then and only then would i proceed with the parity drive replacement... But again... BEFORE doing anything please read the guides and be sure that you have all the information and questions(answered) before proceeding... and also echoing Jona attaching Diags would help us understand what is happening, so that we can best help you

I would echo what Jona says here... Replace the failed drive first and then replace the parity drive second