So the GUI/scripts wants to know what spindown setting to tell the drive,
Correct.
but it's going to access the drive in secret regardless, thus keeping it spinning??????
Many different things within the system might be touching the pool. FreeNAS is built upon FreeBSD, which is itself a moving target.
No matter how long-winded or brief you choose to be, DON'T BE GENTLE! I only ask for accuracy and precision.
To your tangential points about NFS, iSCSI.... obviously I'm testing with all my services turned off, I'm noobish but what's with the red herrings of confusion?
Those aren't tangential points. The point is that FreeNAS itself isn't actually involved in processing the protocols that are being served to the network. When a NFS request comes in from the network, it goes through the TCP stack, into the kernel NFSD thread, which then hands it off to ZFS to read the data. ZFS issues the requests to the disk subsystem, which fulfills the request, returning it to the NFSD thread, which then passes it onto the network. At no point is the FreeNAS middleware involved, which means that FreeNAS has no particular opportunity to manage disk spinup when an access occurs.
What I CLEARLY wrote is any plain ol' script (OBVIOUSLY) can know/inquire as to the state of the disk. Again, any constructive advice/insight is appreciated!
Thus FreeNAS .py files shouldn't wake the drives for ANY reason, per the current docs, let alone in such a long-standing troublesome manner (see multitude bug reports and forum postings)
The very act of inquiring about the state of a disk can be sufficient to wake a disk up.
If you can find a place where a FreeNAS .py file is waking the disks without a reason, submit a bug report.
If you can find a place where a FreeBSD system utility, maintenance script, etc., is waking the disks, also submit a bug report.
But there are a whole bunch of problems relating to drive spindown/spinup, which in general is a very complicated topic. It isn't just "my system woke up at some random time", but also goes to much more complex things such as staging of disk spinups in a staggered manner to manage PSU load, optimizing spinups to only spin disks that need to be spun, etc.
I'm straining my noobish mind here but if the issue is that drives behind HBA cards sometimes don't reveal/or allow spindown/sleep state or whatever, that is also manageable in the GUI code. At the very least it should be disclosed rather than obfuscated.
We deal in the realm of PC hardware around here, where very few things are reliably deterministic. There's no guarantee that any given bit of hardware will support a given feature, or that it will even be detectable that it doesn't support a feature. One kind of hard drive will wake up when you talk to it with SMART while another won't. Etc.
But basically here's how this breaks down.
The developers give us FreeNAS for free, it's their way of validating the foundation for TrueNAS, their paid product. I doubt anyone is spinning down disks on TrueNAS, but if/when someone does, and files a bug report, issues related to this will be much more likely to get looked into.
You have access to the FreeNAS box, plus also the source code. You're welcome to locate any problems and submit bug reports, or even to patch the code and submit the patch.
However, since there's a hell of a lot of work that the TrueNAS guys have on their plates to continue creating a viable, sellable product, and since issues with spinning down/up disks isn't among them, my guess is that this isn't going to get a lot of traction. You could try shipping them a case of beer and asking them to look into it.
Re: FreeNAS is a framework... (is that the same as nested wrappers?) where could I find docs regarding this? I have predisposed bias in favor of bsd and zfs, but so far FreeNAS is harshing my buzz.
Your buzz is artificial. FreeNAS is a framework. In a traditional BSD system, you have to manually create your ZFS filesystem, and you have to edit /etc/exports for NFS exports, enable certain things in /etc/rc.conf for NFS service, and then install various bits of software to do reporting and monitoring. And you need to do that for each protocol and thing you want to do with the server. With FreeNAS, someone has done all the hard work, and has presented it under a unified management portal. Underneath, it is still pretty much a standard NanoBSD image of FreeBSD, and FreeNAS configures all that stuff for you. That's what the framework is.