xpevenom

Yea that makes good sense. For my own sake, will repeat my take away: As you say, given the age of the HP Gen8 Micro, its looks like best value path forward would be: - Split the main 8 disk data array between the onboard 4 ports + first 4 ports of the LSI 9211. This is easy enough - swapping the 3 SFF8087 cables, with disks 1-4 going onboard, disks 5-8 to LSI 9211 Slot 1, and disks 9-12 to LSI 9211 Slot 2. I'm assuming there shouldn't be any array issues after swapping the cables around - drives will be recognized and picked up by the array the next boot. - Out of the remaining 4 ports of the LSI 9211, first two are used as nice SSD RAID1 for things like docker etc. - The remaining two will be see as external eSATA drives: Modifications to synoinfo.conf can be made to switch them to internal drives, but since updates could potentially disable access to them, they ideally only should be used for read-only cache (that is not even necessary, but hey, got an empty SSD so why not). Longer term, replacing the motherboard with something more modern and good support would be ideal. I'm thinking probably will have to wait and see what DSM7 will allow, if it ever comes out and gets support from the community. Thanks again, getting some life out of increasingly obsolete HP Gen8 Microserver w/ Xeon 12xx chip (thats still faster than most factory units being shipped today.... 🤦‍♂️)

Hmm very interesting. Thanks for the details, that helps better explain what options are. Takeaways: 1. If have more than 12 ports, 918 jun loader is patched to 16 disks. Might of made more sense to use that loader vs the 3617 loader (which sticks to the default 12) 2. RAID failure due to missing disks (more disks gone than redundancy allows) results in RAID not starting but recovers gracefully once the disks are seen once again. If only the redundancy disks are missing, the RAID will start and returning the missing disks will require them to be rebuilt (time + strain on the disks). 3. For the particular case of HP Gen8 MicroSever with LSI 9211: Using the onboard ports + first 4 ports of the LSI 9211 should allow for an 8 disk array to not degrade after major update. The remaining 4 ports can used for SSD array (2 to be safe) and last 2 for a cache array (which can be safety blown away without concern).

@IG-88On the topic of the kernel commands vs synoinfo.conf HP Gen8 MicroServer w/ LSI 9211 HBA running 6.2.2 DS3617xs w/ 1.03b loader. Note: motherboard is no longer living in original chassis, migrated to new chassis with 8 drive bays. Running one critical tweak - modified both synoinfo.conf's: usbportcfg="0x7c000" esataportcfg="0x0000" internalportcfg="0x3fff" Without this modification, default DS3617xs configuration detects the last two ports of the LSI 9211 as eSata. After the edit, a volume using all 8 ports of the LSI 9211 is created. Did an update from 6.2.2 to 6.2.3 Update 2. Box rebooted, update seemed to apply successfully and onboard nic works... but array comes up degraded with last 2 drives missing from array. Why? All 8 ports of the LSI 9211 are used in array, update rewrote `/etc.defaults/synoinfo.conf` (but not `/etc/synoinfo.conf`) and so now the last two 2 drives are being detected as eSata external disks. Manually editing `/etc.defaults/synoinfo.conf`, rebooting, allows for the last two drives to be visible now as internal drives. Triggered a repair of storage pool, which is reinitializing the data on last two drives. So array is rebuilding but overall looks like same unpleasantry could happen with next minor update. Issue never noticed before because never maxed out all 8 ports of the LSI 9211 (last 2-4 ports were not used). Roughly speaking it seems editing synoinfo.conf will blow up in your face if used to enable some external ports as internal ports. Wonder is there: A) Way to utilize the kernel/grub commands to achieve same results as I outlined above? I am assuming the grub based kernel commands would persist across an update where as synoinfo.conf edits will not. B) Way to update and not degrade an array that depends on default external ports being mapped to internal? (Preferably without having to LiveCD after patch applied) C) A better way to do this? Or just not recommend port remapping because update will degrade the array.