Can I delete a two SSD Raid 0?

Hey Barry,

This is an old thread, but I just wanted to let you know that your post fixed my issue. I appreciate it!

Cheers,

Johnney

raid does not give Recovery. You must consider that fact. Also if the SSD are not built for raid then a bad idea anyway. I learned the hard way on that point. They'll tend to be bricked.

RAID gets its speed from overlapping seeks on multiple drives. This increase is almost exclusively on LARGE sequential file transfers. The increase is most dramatic on rotating drives with long seek times.

Mac OS X does not do large file transfers, it "snacks" randomly from all over the drive. Mac OS X is a poor candidate for a RAID volume at all. If you have the Liberty of using multiple drives, Mac OS X benefits more from being on a "pure" SSD than on a Mac OS X "Fusion" drive.

I suggest you put Mac OS X System, Library, Applications, and the Hidden Unix files on a Single fast SSD (not a RAID) and declare yourself the winner and still champion. User files are moved off to other Volumes, which may benefit more from RAID.

Use of TRIM is essential for maintaining high-speed access.

The best use of fast SSD RAIDs is for scratch Volumes and frequently-accessed Libraries.

Controllers can brick maybe, maybe the internal SSD controller, but SSDs are fine for use in an array, but realize like any array to have multiple backups or use it for scratch - where you ERASE or DESTROY/DELETE the array regularly.

SSD use hit mainstream almost 6 yrs ago, and has changed a LOT with major changes about in two-year cycles.

There is always a way to re-partition. Depends where and what you did but booting from say flash-based OS X installer you created is one way, and with the latest version of CCC can't see why it would want to create or complain about Recovery. In another thread already today I said, just ignore the need, you don't need to have more than one usually, and definitely not on an array.

What does Recovery buy you? to reinstall OS X over network? you have your saved installer package .ESD. To repair? you have you alernate boot drives.

No benefit. And no mention of what or any PCIe controller - assuming you use and have one. Definitely no to use of SATA II for SSDs for an array. They can't keep up as it is already. Don't have the bandwidth so doesn't make sense to unless you have one of the good RAID capable SSD controllers. And maybe the fault is there.

Usually clonging to an array on PCIe works. Not always. (Do people think make, model of parts used are of no consequence to troubleshooting?)

I know this is a late reply but just to help others reading this - Raid 0 drives on Mac cannot contain a Recovery Partition. This isn't a particular problem. You can and probably should create a suitable USB stick to use for Recovery. However more importantly you will have designed your Raid 0 to be backed up continuously in case of disaster, preferably by Time Machine. I ran a Raid 0 of 2 x 256Gb ssds for the last year in an iMac without a hiccup and am about to upgrade to 2 x 480Gb, with even better read/write times. The 2 x 256Gbs were changed back to individual disks using Disk Utility.

I don't know if this will help or not, but I did have a problem in attempting to "De-Construct" a RAID array that got broken somehow and I wanted to change the striping from mirrored (RAID 1) to RAID 0. Since this was a LaCie External Little Bisk 250GB SSD, I wrote to them and received a reply (the Disk Utility application cannot "De-Construct" a RAID array once created by that application, but it can be easily accomplished via Terminal using the Command Line:

DE-Construct a LaCie Little Bog Disk RAID Array

From LaCie Technical Support on May 29, 2014

IMPORTANT NOTE: The procedure below involves the use of the Terminal program. This program, if used incorrectly, can cause data loss, or other problems. Ensure everything is typed precisely to avoid data loss.

Ensure an up to date backup exists prior to starting this process. It is important to ensure you do not have any other removable drives attached to the computer other than the one we are working with during this process.

1. Open the program "Terminal". This is within the Utilities folder (MacHD --> Applications --> Utilities)

In the terminal window, type:

diskutil list

then press enter. Ensure this is all lower-case, as everything is case-sensitive within Terminal.

This command will return a list of all the attached drives on the computer by a unique hardware identifier. (e.g. disk1, disk1s1). At this point, you will need to determine the correct identifier for the drive we are working with.

2. If you are having problems getting the volume to dismount in Disk Utility, you can use the following command:

diskutil unmount force (identifier)

This step is not necessary if the volume for the drive we're working with is already unmounted. In that case, proceed to the next step.

3. One of the disk identifier entries may show the overall RAID set that was configured on the drives. If that is present, use the following command to remove this item:

diskutil appleraid delete (identifier)

Again, if the RAID set is not visible in the listing shown in step 1, then proceed to the next step.

4. The following command will completely eradicate any remaining header information on the individual disks. This command would need to be done for each disk in the array:

diskutil zerodisk (identifier)

Please be very careful when running this command. This will fully wipe all data from the target drive(s). This should, however, clear off the inaccurate header indication on the drive that is incorrectly telling Disk Utility the drive is "broken".

This process will start a long zero-out procedure on the drive. If you wish to test the hardware integrity of the drive mechanism, you can let this process complete to 100%. If this completes without errors, then we know the hardware of the drive mechanism is completely healthy. This will take several hours to finish on most systems.

If you do not wish to wait, then you can usually interrupt this process (Control + C will abort this) after a minute or two. The important header information is one of the first things to be erased by this process, so even if interrupted, this command should still correct the problem.

5. After everything is finished, you should be able to exit Terminal, and go back into the Disk Utility Application to re-configure the RAID array on the device.

Hope this is helpful,

Barry