Michael H

i think the double wide is because one of the cables actually goes to 2 connections on the backplane (the other one has half as many connections): https://www.houseofsystems.de/778559-001 the backplane i have is here: https://www.serverschmiede.com/de/hp-dl380-gen9-g9-12x-35-lff-hdd-12g-sas-sata-backplane-742794-001-777284-001 maybe from that port you can tell me what hba and cables to get? with my limited knowledge i would say i need s card that has 4 ssf-8087 ports and 3 ssf-8087 to ssf-8087 cables? sorry to bother you, but server hardware is not my strong side and 250 euros+ is not something i want to blindly try... and back to the topic: as you are the disk controller wizard: have you seen this "no spindown" behaviour with other cards and is it common that they only spin up the data and not the parity drive?

i wouldnt mind replacing it, but i have no idea how to check what would be compatible with my backplane. is there anything in particular i have to worry about? or can i just google pictures from connectors to find out what kind of connector that is and buy a card that has 2 of the same?

parity is a 10 tb seagate ironwolf, the 2 data disks are 10 tb wd red. all connected via the hp p840 raid controller in hba mode. something about the raid controller is already fishy, as for smart data i had to manually set all drives to smart controller type = sat to show temperatures on the main tab, although with default smart also worked but would only show * in main tab as temperature.

That was my first idea as well and i double and triple checked every single container and vm. anyways, just so that i quadruple-check again i stopped vm and docker service like you said, spun down disks and like clockwork they spin up again even before i start to miss my internet access (because pfsense is down): Jan 17 15:35:27 hp avahi-daemon[4341]: Withdrawing address record for 192.168.122.1 on virbr0. Jan 17 15:35:27 hp root: Network a67b7b9b-bef4-488b-b243-c9e5f391a3b1 destroyed Jan 17 15:35:27 hp root: Jan 17 15:35:30 hp root: Stopping virtlogd... Jan 17 15:35:31 hp root: Stopping virtlockd... Jan 17 15:35:32 hp emhttpd: shcmd (78933): umount /etc/libvirt Jan 17 15:35:45 hp emhttpd: spinning down /dev/sdc Jan 17 15:35:47 hp emhttpd: spinning down /dev/sdf Jan 17 15:36:12 hp nmbd[1511]: [2022/01/17 15:36:12.357874, 0] ../../source3/libsmb/nmblib.c:922(send_udp) Jan 17 15:36:12 hp nmbd[1511]: Packet send failed to 192.168.122.255(138) ERRNO=Network is unreachable Jan 17 15:41:49 hp emhttpd: read SMART /dev/sdc Jan 17 15:42:02 hp emhttpd: read SMART /dev/sdf and its always sdc first and half a minute later sdf (disk 1 & 2 of the array)...

i did that now, plex docker was also offline for good measure. disks came back from spindown twice BUT: read and write counter did not increase. so now i suspect that my wd red drives do not spin down correctly or at lease report their status wrong... that would also fit to my observation that parity does not spin up on its own. coicidentally, this is an ironwolf drive, not a wd red... i wish i had more ironwolfs for testing this theory... what i would like to try next is disabling smart. i know that smart should skip spun down disks, but maybe the problem is there. if it was "real" disc access, i would assume the read counter would increase. unfortunately i have no idea how i would do that... do you know by any chance? i know its not a good thing to do and in the long run id rather have spun up disks and smart reporting, but i would sleep easier when i know what causes the spin up. anyways, diagnostics is attached. thanks for your investment in this issue! hp-diagnostics-20220116-1739.zip

update: cache dirs did not help. safe mode (just for fun) also not. im all out of ideas.

Thanks for the tip with the cache dirs, i will do that and see if that helps. you said your plugin is not made to log that, as it would log too much... do you have a command line tool or tip for me how i could create such a log anyway? i dont mind greping through a few thousand lines, even manually searching would be fine at this point. literally nothing runs and still the disks spin up - i have to find the reason, even if its the last thing i do. at the time of logging i had literally stopped every docker and vm (except pfsense in vm, running from cache only) and the only computer that was on at the time was the one where i was accessing the gui from, while i made sure that all smb connections from that machine were down. plex container was alsso down at the time of logging. also i have made sure that its appdata is on cache, the automatic jobs are disabled and its not accessible via the internet - so no background file access should take place i guess. especially not when the docker is not started as for the opening of one file in rapid succession... i dont know, seems vlc on mac specific. that would not bother me though, as i wanted that file played, so the disk has to spin up. i only included it in the log to prove to myself that i had the logging set up correctly and it was in fact logging file access. as software seems to be a dead end for now - because if nothing runs, nothing can do anything, in my mind at least and your tool confirms that - i think maybe its the hp hardware p840 raid controller (running in hba mode) that wants to get smart data... that thing is very fuzzy, unraid cant read the smart values from it right - maybe its this combination. i would have no idea what to replace it with though, im not a server hardware compatibility expert...

im sorry, please find it attached. also, here is the output from tonight from your plugin and the tail of syslog: ** Disk 1 ** Jan 15 00:53:10 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E11.avi Jan 15 00:53:10 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E11.avi Jan 15 00:53:10 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E11.avi Jan 15 00:55:53 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E11.avi Jan 15 01:15:11 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E12.avi Jan 15 01:15:12 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E12.avi Jan 15 01:15:12 OPEN => /mnt/disk1/Serien/The Simpsons/S07/The Simpsons - S07E12.avi Jan 15 03:11:29 hp emhttpd: spinning down /dev/sdc Jan 15 03:14:42 hp emhttpd: read SMART /dev/sdc Jan 15 03:22:30 hp emhttpd: spinning down /dev/sdf Jan 15 03:25:42 hp emhttpd: read SMART /dev/sdf Jan 15 03:44:30 hp emhttpd: spinning down /dev/sdc Jan 15 03:47:42 hp emhttpd: read SMART /dev/sdc Jan 15 03:55:31 hp emhttpd: spinning down /dev/sdf Jan 15 03:58:43 hp emhttpd: read SMART /dev/sdf Jan 15 04:17:30 hp emhttpd: spinning down /dev/sdc Jan 15 04:20:43 hp emhttpd: read SMART /dev/sdc Jan 15 04:28:31 hp emhttpd: spinning down /dev/sdf Jan 15 04:31:43 hp emhttpd: read SMART /dev/sdf Jan 15 04:50:31 hp emhttpd: spinning down /dev/sdc Jan 15 04:53:43 hp emhttpd: read SMART /dev/sdc Jan 15 05:01:32 hp emhttpd: spinning down /dev/sdf Jan 15 05:04:44 hp emhttpd: read SMART /dev/sdf Jan 15 05:23:31 hp emhttpd: spinning down /dev/sdc Jan 15 05:26:44 hp emhttpd: read SMART /dev/sdc Jan 15 05:34:32 hp emhttpd: spinning down /dev/sdf Jan 15 05:37:44 hp emhttpd: read SMART /dev/sdf Jan 15 05:56:32 hp emhttpd: spinning down /dev/sdc Jan 15 05:59:44 hp emhttpd: read SMART /dev/sdc Jan 15 06:07:33 hp emhttpd: spinning down /dev/sdf Jan 15 06:10:45 hp emhttpd: read SMART /dev/sdf Jan 15 06:29:32 hp emhttpd: spinning down /dev/sdc Jan 15 06:32:45 hp emhttpd: read SMART /dev/sdc Jan 15 06:40:33 hp emhttpd: spinning down /dev/sdf Jan 15 06:43:45 hp emhttpd: read SMART /dev/sdf Jan 15 07:02:33 hp emhttpd: spinning down /dev/sdc Jan 15 07:05:45 hp emhttpd: read SMART /dev/sdc Jan 15 07:13:33 hp emhttpd: spinning down /dev/sdf Jan 15 07:16:46 hp emhttpd: read SMART /dev/sdf Jan 15 07:26:59 hp emhttpd: read SMART /dev/sdd please focus only on sdd, sdc, scf. the others are not part of the array - i guess you would find that out from diagnostics anyway, but just saying... while creating the diagnostics file i found parity also spinning up, which was also not written into your plugin. so my guess is that its a system job that keeps spinning up the disks, not a file access. hp-diagnostics-20220115-0726.zip

i tried to use this plugin for my specific problem but to no avail. i only get cache drive logs (because of docker / vm stuff), no disk activity logs. so this plugin does not report any file activity on my disks. however, my disks do not stay spun down, as you can see from the log (spin downs are manual): Jan 14 23:54:11 hp emhttpd: spinning down /dev/sdb Jan 14 23:54:11 hp emhttpd: spinning down /dev/sdf Jan 14 23:54:13 hp emhttpd: read SMART /dev/sdb Jan 14 23:54:17 hp emhttpd: spinning up /dev/sdf Jan 14 23:54:27 hp emhttpd: read SMART /dev/sdf Jan 14 23:54:31 hp emhttpd: spinning down /dev/sdb Jan 14 23:54:31 hp emhttpd: spinning down /dev/sdf Jan 14 23:54:34 hp emhttpd: read SMART /dev/sdb Jan 14 23:56:39 hp emhttpd: read SMART /dev/sdc Jan 14 23:56:52 hp emhttpd: read SMART /dev/sdf any idea what else i can try to find the culprit? i have docker and vms completely on cache (libvir, docker.img, appdata...) and all docker containers shut down just to be sure. still, something spins up my disks and at the rate it is happening, i might be better of not spinning them down at all. any hint would be appreciated

downgraded to 6.8.3, no issues (other than had to reformat cache drive becauso of that pool setting in 6.9). @SmokeyOdin: what version are you on?

that you said it could be solved without starting over ;). now i did start over, i backed my flash drive up, formatted it, overwrote it with the contents of a freshly downloaded 6.8.3 zip, restored all my configs from the backup config folder and the super.dat (thanks for that, i would not have thought about that file!) then i had to reformat my cache drive, because of that pool thing in 6.9 and recreated all my dockers (was cache only, but as the appdata is on array, no trouble). for now, the system is behaving like i was used to before 6.9. quick starts, i can stop the array (yay!) and view/edit my vms. it will be a long time before i upgrade to 6.9 again...

i apreciate you taking the time to answer, but unfortunately its not that simple. if it were the adblocker you would not see server side logs of an error/timeout i would think. still, i tested it because i am clinging to every straw at this moment and as suspected, no change in behavior.

i posted my diagnostics in 2 seperate topics already and nobody was able to help. so i would like to bet you 10 bucks youre wrong :D. in case you want to try, here are diagnostics: https://forums.unraid.net/applications/core/interface/file/attachment.php?id=121308

My System i messed up. It takes forever to come up with the nginx webgui (about 10 to 15 minutes until the login to console is available i can finally see nginx starting in the syslog), my VM Tab does not open, i cant manually stop my array or have a clean reboot/shutdown. when i stop the vm service i cant restart it, because the unmount of libvirt img is bad and so on. so i want to start over (already after 1 month of using it - personally i dont think 6.9 is a good release) but i dont want to lose my data and if possible, my vm and docker configurations. are there any ideas/guides how i can create a fresh install but keep data/docker/vms? if possible, i would like to reuse my flash because i dont want to have to transfer my license key already...