joeschmuck, thanks a million for your reply.
It seems that GUI settings doesn't have an effect. So I did a little CLI-based testing using console (and later on using the shell via GUI) after carefully reading the whole thread again.
Additional information about the setup:
- OS is installed on a separate SSD
- logsystem is installed on an USB stick
- no system data or log information stored on data disks
- overall 9 data (pool) disks (all SATA, WD Red, 3 TB), 1 disk connected directly to the SATA-port (ada0), 8 disks connected to the HBA (da0 - da7)
My summary:
1. You are right. It's very easy to spin down disks connected to an HBA via CLI manually. 2. Issuing the command camcontrol standby /dev/(a)daX - t 600 stops spinning all disk(s) immediately.
2. I'm unsure why - the -t parameter seems to be ignored. Is it? Shouldn't the disks stop with a delay of 10 minutes?
3. Disks keep spun down during a 24-h-period. NFS-mounts/-umounts (but no file access) and using the Web-GUI don't affect the pool disks. No scheduled scrubs during this period.
4. Trying to access a file in a NFS-mounted directory after this 24-h-period of inactivity leads into an I/O error (drives don't spin up). However, accessing files locally via GUI-Shell works fine. Hm, maybe an NFS-issue? I'll do a little bit more research on it. That's OT here, I think.
5. Once running, disks won't spin down again, obviously there's no timer set with the camcontrol command (or ignored) - and - again - GUI settings seem to be ignored.
Now, what can I do to make the spindown-command persistent? For sure it's a silly idea to enter the command manually after using the system

and after reboot/update.
Many thanks again for your support!
Mat