New to macOS, mid-2012 Macbook Pro 15, dual SSD raid0 questions

[blehxpo]

Hi, Im new here and new to macOS.
I recently got a mid-2012 Macbook Pro 15, and have some concerns.
My purpose is for some light video editing and some PS work. And some fun with to learn more about macs.

I bought the Macbook Pro 15 cuz it can use dual SSD in raid0, Can the Macbook Pro 13 Mid-2012(i kinda like this size better) also use dual SSD in raid0 with the same speed?

Whats the best option for doing this dual SSD raid0 (high sierra or mojave)?? And best way to do so?

My OS is mojave in apfs format. I think mojave can only be installed onto apfs, but some say that it doesnt support raid0? or is very slow in raid0?

Or is there a way to installed mojave on hps+(macos extended)?

Or should i downgrade to high sierra in hps+ and raid0?

Does it work if i setup my two ssd raid0 first as external drives and CCC to clone my current os on to the external drives then replace the drives.



Thanks!!

 

[casperes1996]

macOS Mojave does not officially support installation on RAID volumes (Software RAID at least. It should work no issue under hardware RAID since, well, it's hardware so the OS shouldn't care)
It can be cloned onto a RAID setup and work fine, but future updates won't be supported without installing to a non-RAID setup and cloning back again each time an update needs installing, which is not nice. RAID is however supported for data only drives that don't hold the boot volume.

 

[blehxpo]

i see, so is High Sierra > Mojave if i really want to do this?

 

[treekram]

I had (emphasis on "HAD") a RAID0 on my mid-2012 MBP running Sierra. My observation is that there is really only one type of task that would benefit from a software RAID0 setup as it has been implemented in macOS. That task is the copying of files. Besides the regular OS copying of files, one might have an app where there is a task where it mainly copies files and that would qualify as well. I have a DVR box and in the app which runs it, you can manually cut out portions of a program and then save it, saving the space that was taken by commercials or whatever I didn't want. So that one task was the only one where I saw a big performance increase. When I had to export the program to view on another computer, it wouldn't be that fast because the transcoding (very light compression so it was pretty quick) couldn't keep up with the speed of the RAID0-enhanced disk-writing performance. Also, the copying advantage only applies to copying within the RAID disks unless you have a Thunderbolt drive that can do over 500MB/sec, but those drives are expensive. I did testing on database tasks that took minutes to do - some tasks were slightly slower, some slightly faster than another computer with a conventional setup. With the software RAID0 as implemented in macOS, the block size is pretty large - 32K is what some people say so there is no advantage in handling of smaller files (none whatsoever unless the file is larger than 32K). Besides copying of files, there are very few tasks where the 2012 MBP can process data fast enough to take advantage of RAID0 speeds over a long enough period of time for people to notice a difference.

Now, when it was easy to set up RAID0 and when there was no issues like there are with High Sierra and Mojave, my advice was there was no big downside to using RAID. But you really need to think about the tasks you do before doing RAID0 in either High Sierra or Mojave.

 

[casperes1996]

I had (emphasis on "HAD") a RAID0 on my mid-2012 MBP running Sierra. My observation is that there is really only one type of task that would benefit from a software RAID0 setup as it has been implemented in macOS. That task is the copying of files. Besides the regular OS copying of files, one might have an app where there is a task where it mainly copies files and that would qualify as well. I have a DVR box and in the app which runs it, you can manually cut out portions of a program and then save it, saving the space that was taken by commercials or whatever I didn't want. So that one task was the only one where I saw a big performance increase. When I had to export the program to view on another computer, it wouldn't be that fast because the transcoding (very light compression so it was pretty quick) couldn't keep up with the speed of the RAID0-enhanced disk-writing performance. Also, the copying advantage only applies to copying within the RAID disks unless you have a Thunderbolt drive that can do over 500MB/sec, but those drives are expensive. I did testing on database tasks that took minutes to do - some tasks were slightly slower, some slightly faster than another computer with a conventional setup. With the software RAID0 as implemented in macOS, the block size is pretty large - 32K is what some people say so there is no advantage in handling of smaller files (none whatsoever unless the file is larger than 32K). Besides copying of files, there are very few tasks where the 2012 MBP can process data fast enough to take advantage of RAID0 speeds over a long enough period of time for people to notice a difference.

Now, when it was easy to set up RAID0 and when there was no issues like there are with High Sierra and Mojave, my advice was there was no big downside to using RAID. But you really need to think about the tasks you do before doing RAID0 in either High Sierra or Mojave.

I will add to this that if you really want it is possible to adjust the block size, both with Apple RAID (if you use the Terminal) and more easily with other tools, like SoftRaid

 

[treekram]

I will add to this that if you really want it is possible to adjust the block size, both with Apple RAID (if you use the Terminal) and more easily with other tools, like SoftRaid

So I must have created my RAID0 in El Capitan, which didn't have a tool in Disk Utility to create the RAID and at the time and the block size couldn't be specified in the command-line utility or people said it had no effect on the actual block size used. I see that it did come back in the Sierra Disk Utility with the ability to specify block sizes of 16K, 32K, 64K, 128K, 256K. Thanks for pointing that out.