I am running on 6.8.3 and have been for several weeks.  I also started to use containers.

 

Problem: unRaid keeps two drives (parity + 1 data disk) spun up with a high volume of rites to that disk share docker/docker.img

Even if I remove container capability (container settings disabled) and any containers I have installed the problem still exists.

This can't be good for the life of the drives. There are no errors showing up

 

Is this problem rectified in 6.9 or is there something I can do now on 6.8.3 to correct it?

So long as you have the docker.img set on the array, you will pretty much always have the 2 drives spun up.  Every container is like a miniature OS, and every write will keep those 2 drives spun up.  By and large the vast majority of people place the docker.img file onto a cache drive which is outside of the parity protected array so that 2 drives do not always need to be spun up.  Reason why stopping the containers doesn't fix the spindown is that the service itself is still running.

 

But, yes 6.9 does solve the excessive write issue (really only affected certain SSDs)

So, could I add a small drive (cache drive ?) to hold the docker.img.  I would not like it to be part of the array but I guess that shouldn't matter.  The system has 1 100 GB drive that is not part of the array.  I had used it as an alternate boot drive for Windows, but I never use it.  It is inside the chassis instead of being in a swappable bay.  How would I go about using that drive to hold the docker.img and perhaps appdata also?

No problem setting up a drive for that purpose, and that is the normal way that is recommended.  Despite the ‘cache’ in the name there is no reason you cannot use it purely for applications. Even more so with the 6.9.0 release where multiple ‘pools’ are possible, each of which can be optimised for different usage types.