Since the large array is on a controller of a separate type (make and model, or rather: chipset), and nothing on it is needed for the system boot process, you can work around this by forcing a delayed controller initialization. The easiest way to do that is to simply blacklist the kernel module that does the kernel initialization, then load it manually very late in the boot process.
NOTE: It is extremely important that this is done only with controllers that hold nothing that is needed for the system to boot properly. Otherwise, you will find yourself with a boot failure - anything from services failing to start or reading/writing files in the wrong place, to an outright kernel panic. Keep this in mind before implementing a scheme like this.
First, find out which kernel module handles the controller in question. A quick Google search based on the information provided in the question says this likely indeed is the
mpt2sas module. Second, make sure that the code is actually compiled as a module; something like
find "/lib/modules/$(uname -r)" -name 'mpt2sas*' -print will do nicely. (Yes, I know that
-print is the default, but I like to be explicit...) Verify its status as a loaded module using
lsmod | grep mpt2sas.
Then, add the module to the modules blacklist file. You can either add it to /etc/modprobe.d/blacklist.conf, or a separate configuration file such as /etc/modprobe.d/mpt2sas.conf. Just add the following line to such a file.
This will disable automatic loading of the module in question. We are going to take advantage of the fact that it can still be loaded manually using e.g. modprobe - where "manually" can mean "from a script".
Open /etc/rc.local (which is executed after all other rc scripts) in an editor, and add the following lines somewhere in it:
You probably want to put this late in the file, but obviously before any
exit or similar directives. The
mount -a may or may not be needed depending on whether the file systems are actually to be mounted on boot and whether they are mounted automatically when they are found by the kernel disk partition probing. You can try without it first, if you want to and feel safe that you can gain access to the system if it doesn't work. If you need anything special to start up RAID or somesuch, that goes between the
mount. If any specific services need the large array to be available, you can create a separate rc script to start the array and specify that it should run before any such services are started. You can make it execute in the background by wrapping it in a subshell with a syntax like
( commands ) &, but that may or may not have any noticable effect on the result because partition probing is done in the kernel. You may be able to use
hdparm to spin down the drives after the partition has been mounted, if they are only rarely accessed. In short, this is the part you may want to customize for your particular needs.
Then, update your initramfs by executing
update-initramfs -u as root.
If nothing failed, you should now be able to
reboot your system and enjoy the benefits of delayed disk spin-up and partition probing.