ishbuggy

Ah okay. That sucks, I was hoping the newer ones would help the system get to higher C-States than C2. Maybe at some point I'll look into switching it for a SATA expander.

I am having trouble getting below C2 on my server. My system hardware is: Motherboard: MSI MPG B760I EDGE WIFI DDR4 Mini ITX CPU: i5-13500 RAM: Corsair Vengeance LPX 64 GB (2 x 32 GB) DDR4-3200 CL16 Memory NVME: 2x Samsung 970 EVO 1 TB SATA SSD: 2x Samsung 870 EVO 2 TB (connected to MB SATA5, SATA6) PCIe HBA: Broadcom 9500-8i (SAS3808) HDDs (connected to HBA) 2x Seagate Exos X20 20 TB 2x Seagate Exos X16 16 TB 1x Western Digital Red 8 TB PSU: Corsair RM750x (2021) (Not the 550x, but so far seems only slightly worse) I have configured everything I know how to in the BIOS and run all the powertune commands in this post to try to allow all the devices to get to a higher C-State. I previously had a LSI-9207-8i that I sold before rebuilding this with the 9500-8i. The 9207-8i definitely did not support L0 or L1 states, and I narrowed down to be the cause of my system never going higher than C2. The command mgutt gave to list which devices supported L1/L0 link states reported that the 9207-8i did not have any support, as expected as it is an old device. I expected the 9500-8i would be better. It does have much lower power consumption itself, but it seems to be still the cause of my system not getting any better than C2. When I remove it, I can reach C6, but with it installed it can reach only C2. The link state support listed (and in the broadcom documentation), shows that it should support at least L0, and I should have enabled it in the BIOS. Yet still, the system cannot get there. Does anyone here have an idea why not? I have updated the firmware on the HBA, but that so far did not change the behavior. Is it something to do with the mainboard? I didn't realize until recently that MSI has a bad reputation here, but I still don't think this is on MSI for sure. I am not sure why it doesn't get higher than C6... but that can be a problem for another day haha. I would really like to get to C6 at least to start. My idle consumption right now is around 33 W (drives spun down), and I'm sure it can go much lower if the package can sleep properly. With the 9500-8i attached: Without the 9500-8i attached:

Thanks for the help! Disk2 does indeed have files in that share. I think what I didn't understand is that it must read the disk when anything in that share is accessed or modified, regardless of whether it currently exists on the cache drive or not. In the end, I was able to "fix" it a bit by disbaling file history in windows, and reverting back to using only veeam for backup. I tried the "folder caching" plugin, but the default without user shares didnt fix it. User shares included did fix the spin up problem, but led to much higher CPU usage that more than negated all the power gains from sinning down disks because it could never sleep. So, for now I guess I consider this solved for me.

Also, those lines in the screenshot with file names are not syslog, they are from the File Activity plugin. I have been using that to try to debug what is causing the disk spinup

Ah no, I didn't edit them, but I made the diagnostic log a little while after I made the screenshots of the syslog. And yeah, I don't understand why it shows on disk2. When I browse into disk2, it does not show the files having been updated. That only shows when I browse to the cache. But yeah, the File Activity log shows that disk2 was accessed. I cannot understand why though.

I am a bit of a noob with Unraid, so I apologize if I don't describe everything correctly. My server diagnostics are here: server02-diagnostics-20230915-1422.zip I am running Unraid 6.12.3, and I'm having an issue where file access on an SMB share is causing the disks to spin-up in the array when they shouldn't. It is happening with multiple shares, but I included an example in the screenshots. The share is set to use the cache first, then move to array. But when I access it via SMB on another windows computer, it will work, but it spins up the disks when filed in the share are edited. I cannot figure out why the disks are being spun up here. When I check the files on the disk itself, they are not modified. It still contains the old version, as mover has not yet been run. The modification is present in the cache drive as expected. Is there any way to change this so the disks stop being spun up? I thought that the share being cache first would mean that all activity would happen on the cache drives, and never touch the array until mover is called. So far this is negating a lot of power reduction I am trying to accomplish by spinning down disks. This happens for other shares as well, including, very annoyingly, my backup share where I have windows file history backups, set up following SpaceInvaderOne's video. This means that almost when I do anything on my desktop, it will inevitably spin up the relevant disk and parity disk.