Kurtains

Thank you for redirecting me. I have followed the steps (but I had to use openSeaChest as using the latest official tool would require different instructions/steps to follow) and it looks all the drives have kept those settings as disabled after the restart. I've changed the default spin-down delay back to 30min and here's hoping that fixed it! I'll come back and mark as solution if there's no issues by the end of the week. Thanks again EDIT: Appears to be running fine, spin ups have been few but so far no errors. I'm cautious to call it a success but with all the drives spun down the "idle" power usage has dropped 60-100W which is a pretty significant reduction for a device that's on 24/7.

I have found a couple of similar posts but none with a resounding "cause" of this issue. I have enabled spin down for the drives in my array a couple of days ago to try and reduced power usage and heat, but I checked it today and disk 2 is disabled. After reading another post where a reboot can solve, I have tried that but it's still disabled. I realize I should have done diagnostics before restarting, but I'm attaching in case it's of any use. I'm certain the supermicro PSU breakout board, backplane, HBA adapter or cables aren't the issue because it has been running fine for years and before this recent restart it was up for 30 days straight. If the drives never spin down, it's not an issue, but if spinning down is allowed, eventually there is a disabled drive. Why might this be and what can I do to check? Full disclosure, I tried this in the past a couple of years ago and had the same result, so I stopped allowing spin down. I'd ideally like drives to be able to spin down due to concerns about regularly high temps. Thank you citadel-diagnostics-20240728-1138.zip

The extended test completed with read failure, report which says passed is attached. ST8000NE001-2M7101_WSDA5J92-20230803-0311.txt

Why do you think it's a power/connection issue? I recently checked connections after doing some dusting inside the rack and case, plus it seems weird that it would be just one drive that's connected up to the backplane and not multiple/surrounding drives to also have issues right? The first (oldest) of those two attached smart reports is an extended one, from only a little time ago - will an extended one even complete if I can't currently run a short test as it finishes moments after starting "completed: read failure"?

Hi all, I haven't particularly had this issue come up before where parity check has stalled after ~12 hours into a typical ~22hr parity check on the first of each month. I got two errors at the same time - Warning (Array has 1 disk with read errors), and Alert (Disk 12 in error state disk dsbl). The disk shows in unassigned devices and with just a format button. Nothing in the syslog spoke to me as to the root issue and I wanted to check here before proceeding with an attempt to restart array without the drive selected, and then start with it selected to perform rebuild/sync. Currently the page is hanging when I select to proceed with canceling said stalled parity check, hoping to not do a force shutdown/restart. Diagnostics attached but also SMART report for disk 12 from a couple of weeks ago. Thanks Edit: I had to shutdown the machine as the 'main' page was unresponsive and I couldn't cancel the stalled parity check via parity.check plugin. Disk 12 was rather noisy when booting back up, smart test completed: read failure, but still says passed. attaching new smart report. citadel-diagnostics-20230802-0630.zip ST8000NE001-2M7101_WSDA5J92-20230717-1323.txt ST8000NE001-2M7101_WSDA5J92-20230802-0906.txt

A couple of weeks ago I added 4 new drives to complete my array, one of them was for parity 2 and the others were to be added to my media share and I was on 6.12.1. Instead I decided to make a new share with existing media containing drives and these new ones then copy media from one share to another (there's probably a way better way to do this but it's mostly done now). About 12hrs+ through transferring files disk 1 was showing as disabled and I could then see it in unassigned devices. I checked the data was all still there then rebooted and let parity sync always without errors. This happened about 3 times in total with disk 1 and disk 2, with varying lengths of times into transfers, sometimes requiring hard restarts because I suspect mc still had an open session somewhere which had been closed on my browser and I could no longer access. It's happened a fourth time then I found this thread and decided to roll back to 6.11 and I've run extended smart tests on all 16 disks which are doing well. I had to add my existing docker containers via template to get them to work again as most of them wouldn't start after the rollback. Adding diagnostics here for either the unraid team and/or anyone that confirm the link between 6.12.x and drive issues citadel-diagnostics-20230718-0703.zip