PeterDB

I think this is actually the best advice! I wish a PSU manufacturer would make a power supply with more than maximum 6 SATA power connectors, because otherwise your options are dual power supply, (noisy) enterprise power supply, AliExpress expansion boards or custom cables

From 2021.. try a newer drive like the Exos X24 https://www.seagate.com/content/dam/seagate/assets/support/internal-hard-drive/enterprise-hard-drives/exos-x24/_shared/files/Seagate_EXOS24_CMR_ISE_SED(10-12-16-20-24TB).pdf which has a max startup of 2.36A on 12v and only AC peak DC, while the steady DC Peak DC is 2.035A

While I agree that regular users shouldn't attempt this, but I consider Unraid users and users who reach this thread ones who do need more help and often do need to look into making their own cables. I'm personally already at 27 disks, and building an enclosure to fit 40+

Valid point, I just checked myself and you are right (don't hear that a lot online :) )... Command is issued but the Adaptec 71605 HBA I'm using is causing the staggering, not Unraid.

There is a reason for 4, which is the old rating for 3A per disk during inrush/power on, and that most older PSUs only delivered 12A per molex connected (4 connectors X 3A = 12A). However, a good high voltage platinum or titanium single rail PSU can easily handle 50A. My Corsair HX1200v2 can handle 100A on the +12V rail, and 30A on the 5V. Only considering the 12V rail that would be 33 disks. Now if you do that all on one single string the cable would be the limiting factor. If the PSU can handle it then really it becomes the cables AWG rating that needs to be looked on. On a 17 AWG cable, which is the max you can fit in a molex connector using a punch (higher if you solder) then it's 14A, and then we are back at 4 disks if considering 3A inrush. But! Disks don't use 3A inrush on the 12V rail, it's split usually 2-2.4A on 12V and 0.2-0.8A on 5V. Added to this, if you have a decent native HBA controller like a higher end LSI, HPE or better yet Adaptec, then staggered spin up is part of the basic firmware. Even Unraid itself will stagger spin up on shutdown or all disks active. What does this mean? Make your own cables and max 7-8 per cable!

Just read the latest newsletter and it's officially mentioned that the What's coming in 2026 section: Multiple Arrays Expanded storage configuration capabilities to support more advanced and diverse use cases. Yay..

Thanks @JorgeB this good info.

Honestly more of an interpretation of the all the recent release notes, that promote pools. However, it is good to know it's coming. I would like to see LimeTech pursue it more, especially now that we see a rapid increase in HDD prices and there doesn't seem to be any end in sight. I already saw 20TB Exo drives increase100 Euros in less than a month.

Hi! I'm running almost at capacity with the array, in the sense of amount of disks. Right now I'm at 22 disks totaling 320TB plus one parity drive (I know, but I've never had a failure)... I could start to upgrade the disks, but doing the math I could start migrating to 28TB drives, or moving 8TB to 20TB, but cost of moving to 28TB would be around 8-10K euros, less than ideal. While I understand that dual or larger arrays doesn't seem to be coming in the near-term future, ZFS pools seems the path forward, specially also since a pool can have 200 disks. But I have some questions: Can a ZFS pool (or any pool) spin up only the disk being read/written to? Which type of ZFS pool is best used for large amounts of disks? My initla tests using trial seems to spin up all the disks, but if I read TrueNAS' documentation they only spin up the disk in use.

I'd like to know this as well, because the new pools with ZFS drive by drive scaling was promoted as "the new arrays". However, if all the disks in a pool spin up, it's pointless. I'm at 23 disks, and usually scale 2-3 disks per year, which means I'm running out of slots soon.

Just to comment, as I'm was a similar situation. It's not ideal, by any means, and you run the risk of shorting the drives. (I've personally had this happen) Option: Get a power supply with 6 SATA connectors. I have a Corsair HX1200 v2 and I have 7 drives per SATA connector. Option: Seing how HakoForge and 45drives do their power spliiting from PCIe GPU power connectors, I found this on a certain Chinese online site my friend Ali recommended under the name "ATX 6/8Pin 12V to 5/12V 4x 4PIN + 4x 5PIN Power Supply Breakout Board Module Adapter Connector for ATX PSU 2.5/3.5" SATA HDD". One PCIe GPU split it into 4 connectors which provide stable 12v and 5v. I have between 4 and 5 drives attached per molex connector. Each power connector can handle max 3A. (FYI: this is work still in progress, so the build is FAR from done).

Not really the right place, but I know Supermicro boards can be a b* because their fan control runs through the BIOS and ipmi commands. What you could try to do is: Run lm-sensors to see if it works Then run fancontrol to see it works now If it does then try to not use Dynamix but the new FanControl Plus https://forums.unraid.net/topic/191722-plugin-fancrtl-plus If this all fails and you want actual control, you're better off with a fan controller like OpenFan. Sorry couldn't be of more help!

@CkChong I've been testing the plugin, and honestly, you managed to make something that works so much better than the Dynamix System AutoFan plug. I would like to ask, if you would consider extending the support to OpenFanController? Right now users are using the OpenFanController docker to manage access to the device and it's API, and a seperate control docker called OpenFanService to regulate the fan speeds, the latter being a purely text based configuration. Your plugin could be extended to support it via it's API, rather than the scripts you run to set the PWM on the fans at the moment. I'd happily sponsor the OpenFanController, so you can test and build up the support.

You and @SasaKaranovic should team up, as OpenFanController does offer a simple API to control the fans, honestly with your plugin compared with the power OpenFanController would make an amazing combo! Also @CkChong very nice plugin!

For reference for others and just sharing! I was just testing the new Arctic P12 Pro PST 5-Pack because I'm planning to replace all my fans in my cramped Inter-Tech 4F28 chassis. Arctic designed the P12 Pro PST to be daisy-chained and according to their specs they draw 0.33A, but they draw more than that! OpenFanController fan headers are rated at 1.1A and 99% motherboard fan headsers at 1A. No matter what I did, my experience with both my motherboard (Asus Sabertooth X99) and the OpenFanController was the same: If 3 are daisy-chained, connected to one fan header and the PWM exceed 90% > The fans spin down, effectively tripping the fan header fuses. The fans try once in a while to spin up again, but trip the fuses again and spin down. If 2 are daisy-chained, connected to one fan header and the PWM exceed 90% > No issues, so far! No daisy-chaining and one fan per fan header > No issues at all This wasn't really expected behaviour, since the fan specs state 0.33A, so I guess Arctic needs to still improve these new fans, but... I will say at 100% PWM they can push some serious airflow! Heck, even at 50% they are amazing and quiet. My Noctua's are getting retired and getting replaced with these.

@JayBee_Unraid I have both latest versions installed and running without issue. As @SasaKaranovic mentions - and he is correct - some is causing the OpenFanController not to have it's port correctly configured. Can you try to get the log from it (without having OpenFANService running)? You should see the port number there or at least something indicating what the error is. Here's what I see.

Okay, @RandoUser but can i ask why you opted for that fan versus other consumer fans? Is your build in a server room, because its gonna get loud with those fans? I made a similar mistake myself in the past and even my noise cancelling headsets couldn't cut the fan whining out.

I gotta ask @RandoUser 10 fans at 2.7A. that's 27A on the 12V rail, which power supply are you using? I know my Corsair HX1200 can handle max 100A and on multi rails 40A, but 27A for fans is a lot.

hahahah @SasaKaranovic one more minor thing to fix. @K1ng0011 99.1% of consumer fans, except Phantek T56's and some other models, can do more than 2000 RPM. Yes, there are model that do more, but the usage is niche and you wouldn't be able to sit next to the rack either because of the noise at those speeds. Maybe this something Sasa can fix, but there is no feedback mechanism from fans to report up what their max RPM is (at least that I know of).

Hi @K1ng0011 I think you have the same issue as me, the sample profiles yaml is not correct and Saša is aware of this. Update your yaml so that the identifier starts at OpenFAN/Fan/0 not OpenFAN/Fan/1, and update the others too so it's 0 to 9 not 1 to 10. Now test

@SasaKaranovic I found the error! It's the sample_profile.yaml! I went through the logs and saw that OpenFanUnraidService is making the API call to the wrong fan; fan 1 instead of fan 0! The reason being is that the sample_profile.yaml that I copied from https://github.com/SasaKaranovic/OpenFanUnraidService/blob/master/src/sample_profile.yaml it has FAN1 with the identifier OpenFAN/Fan/1 not OpenFAN/Fan/0. Once I made the change, it is now working!

UPDATE: This was resolved here: https://forums.unraid.net/topic/155377-support-sasakaranovic-openfan-controller/page/3/#findComment-1559891 Hi @SasaKaranovic I do have a 4pin PWM Noctua NF-P12 connected to FAN1 and I also have the Unraid Community OpenFanController docker and OpenFanUnraidService installed and running For OpenFanController I left the port at default 3210 and changed nothing: I am able to access OpenFanController docker and it is able to able to manually control FAN1, here it is spun up to 100% PWM with around ~1700 RPM Here is FAN1 at 50% PWM with around ~940 RPM The OpenFanUnraidService is also set up and running with this docker configuration And the fan_profiles.yaml is in /mnt/user/appdata/openfanservice/ With this simple configuration looking only as the cache_nvme and disk1 temps , set with a linear curve and top temperature set to 30 and 100% PWM. The fan_profiles.yaml was built over the included https://github.com/SasaKaranovic/OpenFanUnraidService/blob/master/src/sample_profile.yaml Right now that cache_nvme drive is hitting 39C, and according to the fan_profiles.yaml FAN1 should be at 100% PWM As seen earlier in the earlier screenshot, 100% PWN is ~1700 RPM, but it's only at ~940 RPM This is why I started to check the logs and API calls. I can see from the OpenFanUnraidService that the profile is being created and FAN1 is being set to 100% PWM and also that the cache_nvme drive temperature is seen at 40C. From the OpenFanController logs, I can also see that it is receiving the API call and setting FAN1 to 100%. However, the fan is not adjusting the RPM. Now, you are right, my earlier API calls, had 1 instead of 0 as the selected FAN (I blame that I being up to 3am and emailing you, plus my wife's alarming then going off at 7am again). and when I do use 0 instead of 1, it does spin up to 100% PWM However, how come the fan_profiles.yaml doesn't do this, when it sees that the cache_nvme drive is 40C and the highest point is set to 30,100 (30C 100% PWM)? I tried make the fan_profiles.yaml even more simple and just set 0,100 and only lookg at cache_nvme... but that still didn't make any change I changed again to using RPM.. The OpenFanUnraidService is sending it And OpenFanController is receiving it But that also didn't make any change to the RPM So back again to the quesiton, if the dockers are set up and the API calls are received, how come there is no change? Updating with the logs: logs.zip

UPDATE: This was solved here: https://forums.unraid.net/topic/155377-support-sasakaranovic-openfan-controller/page/3/#findComment-1559891 After some errors on my part getting the OpenFanUnraidService to communicate with the OpenFanController, as I was using port 3000 instead of 3210, I got the communication between them working. However, I noticed that not matter the FanProfiles Points or whether I used RPM or PWM (yes, I set UsePWM to true) the fan speed did not change. I decided to shutdown the OpenFanUnraidService and test the API, so I just used curl and first got the status, which show Fan 1 (only fan connected since I'm testing) at 951. So I set the fan speed to 100% PWM The fan physically didn't do anything, so I got the status again, and the fan is shown still running around ~950 RPM Odd... so I decided to test with profiles. First I created two new profiles PWM50 and PWM100. Then ran status, set PWM100 and ran status again, that worked! Reverted back to PWM50 Now tried again to set the fan 1 PWM and it again failed! It is receiving and setting the PWM but no change. @SasaKaranovic any ideas?

Bummer... If you can get one pwm fan header to work, then split it and use this https://www.amazon.com/Thermalright-Integrated-10-Port-Controller-Support/dp/B09CH31RM6/ If not then maybe CORSAIR iCUE COMMANDER CORE XT Neither worm as good as an OpenFan Or better yet, see if you can find an OpenFan used... Or maybe have it to delivered to a friend somewhere else, maybe Mexico or Canada, then go pick it up from there... Or order it for hotel delivery on your next business or hotel trip.

I ultimately ran into the same issue myself with a new build. I've tried loads of AliExpress and A brand controllers, none work good. Best option you have, but still requires some hands-on to configure is OpenFan https://github.com/SasaKaranovic/OpenFanController i have one now myself