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.
blacklist mpt2sas
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:
modprobe mpt2sas
mount -a
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 modprobe and 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.
mpt2sasmodule to the modules blacklist (assuming that it is compiled as a module), thenmodprobeit from/etc/rc.local? That should at least delay the probing until everything else has started, at the obvious expense of those drives not being available during the boot sequence. Depending on your needs (and assuming nothing critical is on that bus) this may be an acceptable tradeoff./lib/modules/3.2.0-0.bpo.3-amd64/kernel/drivers/scsi/mpt2sas/mpt2sas.koa, so this looks like it is compiled as a module. After blacklisting usingecho 'blacklist mpt2sas' >> /etc/modprobe.d/mpt2sas.confthe drive do still spin up during boot. Am I not blacklisting correctly or isn't mpt2sas a module?update-initramfs -uafter creating that file.update-initramfs -uandrebootthe drives on the mpt2sas bus are no longer detected during boot.