SSD RAIDS...

[Will Keir]

Switched my 2x SSD from Bay 1 & 2 to 3 & 4 respectively and found:

My bootcamp SSD became "disk0"
1x 840 pro SSD became "disk1"
1x 840 pro SSD became "disk2"
and my external USB Flash drive remained "disk3"

Glad I have some healthy soup my wife made to keep me up late figuring this stuff out.

 

[Will Keir]

Plugged the 2x Samsung 840 Pro SSDs back into bay 1 & 2 and the bootcamp SSD remained Disk0. I'm finding no corrolation
between "Connection ID" and disk#, though it seems internal drives take priority over external drives or at least USB Flash drives.

1x840 pro became disk1
1x840 pro became disk2.

Pretty happy with this, a bit more intuitive.


/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *480.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Win7 30.0 GB disk0s2
3: Microsoft Basic Data BOOTCAMP 449.8 GB disk0s3


/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *512.1 GB disk1
1: EFI 209.7 MB disk1s1
2: Apple_HFS Untitled 511.8 GB disk1s2


/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *512.1 GB disk2
1: EFI 209.7 MB disk2s1
2: Apple_HFS Untitled 511.8 GB disk2s2

NOTE: After 1st Reset:
Disk0 Became the Samsung 840 Pro drive.
Disk1 became the bootcamp SSD.
Disk 2 became 840 Pro.

Finally, I just put the 2x SSD back into drive bay 3&4. They seem to remain as Disk1 & Disk2 now, even after shutdown/restarts.

 

[Will Keir]

Now I'm ready to build:

"The catch on the Mac is that Disk Utility will not touch any non-OSX partition, nor will it list or touch any partition flagged by an installer or manufacturer to be hidden or one that is marked as active for Windows or a few other types that are not unusual, just out of scope of the Disk Utility application."

The command "sudo diskutil list disk#" will show what I need? Including flagged partitions, or manufacture hidden ones? This is where I confirm if anything funky is happening with the drives or is this more? To this point, the only new skillset I have learned is how to check the drives before creating the raid with "sudo diskutil list disk#."

My format:

GUID_partition_scheme & Apple HFS Untitled is what I want, correct? (note: I only Disk Utility and "Zero Disk" to prepare the SSD Drives.)
I can now process with building the RAID 0 or do I need to use the "GPT" "FDISK" and "PDISK" commands?

Notice the name for Apple HFS Untitled is "untitled." Is there a difference if I name these "Drive1" "Drive2?" I'm thinking naming them during the Erase process is a better practice than a bunch of "untitled" disk lying around. especially if you are using 4 drives in a Raid Set.

 

[Will Keir]

Question:

Is is better to create the Raid Set in the OS X Installer or within a Mac OS X environment? I noticed in the installer you cannot use "Zero Disk" option in the "Erase" tab.

 

[Jeff Kilgroe]

As you've already discovered, the disk1, disk2, disk3, etc.. assignments can change and are not tied to any specific hardware location. It really just comes down to the order in which the system initializes drives and it tries to cache them if possible, but it doesn't always work out. Best to open up the graphical version of Disk Utility and then you can right (or option) click on the drive in your device list and pull up its info. It will tell you whether it's disk1, disk2, etc.. Then you know which one to reference from the terminal for those operations. Always double check this, because these drive assignments can change every time the system is restarted or even if an external disk is ejected and then reattached to a different port, sometimes to the same port if something else is inserted or mounted as well.

From the terminal window, if you type "diskutil" and nothing else, the disk utility tool will run and show you a list of all its commands. Once you have had diskutil list your drive's partition map, you can then proceed with clearing it. So when ready to clear it, you would type:

sudo diskutil eraseDisk diskN

Where N is the appropriate number for the disk you want to erase. In unix, the sudo command preceding anything else on the command line tells the system that you want to run the command with full root/admin privileges and it will ask for the root user password. This is required anytime you run a command that can incur system-level changes. Just an extra step that keeps you from effing up to bad.

So far, what we have covered can be done in the graphical Disk Utility. However, when you start dealing with consumer grade drives -- like your Samsung SSDs -- you may discover other things on them that graphical Disk Utility won't deal with. This is a constant nightmare right now with external drives, especially those with multiple interfaces where we would like to format them as exFAT. I see on here reports all the time about how the drive shows up under OSX but not Windows or vice versa… 99% of the time, it's a drive partitioning problem. Usually there's a conflicting GPT partition mapping or even a partial header that the OS can't understand, which is offset from the data it actually needs.

Some of my recent HDD and SSD purchases have come with Windows GPT partitions on them marked as active or boot and graphical Disk Utility does not report those, nor does it fully remove that Windows GPT header and this can be a problem when setting up a software RAID in OSX as it will offset the start of the necessary data from one drive to another. On dedicated RAID controllers, this usually isn't much of an issue as they should (usually) wipe whatever is on the drive starting from the very first bit.

In case of some stubborn partition types in terms of a damaged or locked GPT table, you may need to use the GPT command from the terminal command line. This lets you "destroy" a GPT entry on a hard drive.

sudo gpt list diskN

that will show you what's there

sudo gpt destroy diskN

that will destroy the GPT table on the drive

You can type "man gpt" at the command line to get the brief users manual for gpt or just type "OSX gpt" into google search and find it that way.

There is FDISK under OSX that is essentially the same thing, but deals with MBR partitioned drives formatted as FAT. PDISK is another option, but is technically deprecated and replaced by diskutil.

You can get info about those commands the same way, "man fdisk" or "man pdisk" or google them.


Sometimes if a drive's partitioning is totally FUBAR, it's easier to just unmount the drive (if it can even mount to begin with) and then use "dd" to data dump a bunch of zeroes or something to the front of the drive to write over whatever crap is there. Then the OS will see the drive as bare and let you start fresh. I sometimes do that if it's a drive that has been partitioned on Windows and may have a conflicting OSX partition on it.

A lot of what I'm covering here are occasionally necessary operations on any computer. Windows, OSX, Linux… Each OS will have different tools to accomplish these tasks, but it's stuff that the OS's at a general user level will try to shield people from ever seeing or having to deal with.


Based on what you have reported with your listing of drives from diskutil, there doesn't seem to be anything out of the ordinary there and you should just be able to erase those disks and create your RAID set in the graphical Disk Utility. Just boot into OSX as you normally would and run Disk Utility to create your RAID set. Don't need to do it from the installer. Now if you want to get into creative uses of the software RAID, such as actually booting OSX off of it, then you can do that! I do not recommend such things, that's something crazy people do and I have done it in the past. OSX tries its best to keep you from being stupid, but you can clone a perfectly good boot volume and then dump it onto a RAID via a tool like Carbon Copy Cloner.


Now on to other questions… You were having trouble previously with the RAID setup and I know that's what started all the questions. Did you get the RAID up and running properly? Or are you still having issues with it? One concern I have has to do with what I said before about the SSD's not being very good for RAIDs. I have not played with the Samsung 840's much in RAID use, but I had some issues with erratic performance when I did set up a 3 of them in a RAID-0. The SSD's are just not designed or tuned for operation in RAIDs. If you want to build SSD RAIDs, you need to go with SSD's that are intended for that purpose like the OWC Mercury Enterprise Pro or the Toshiba Enterprise RAID units. They're more than double the price per GB vs. desktop-class SSDs like the Samsung 840, but they have larger caches, over-provisioned storage. For example the Toshiba 640GB model is actually has 960GB of flash memory on it. This allows them to keep write speeds up and tunes the SSDs to cycle faster to keep up in a RAID environment. SSDs are fast but the recycle timing on NAND cells is comparatively slow.


One more thing. Once you create your RAID set in Disk Utility and it's time to format it. Choose to erase all free space and zero it out. This step is often overkill, but I always do it on new RAIDs. That way it will zero the entire volume out which can potentially help fight data corruption down the line. It also serves as a quick check to see if the entire volume is writable and working. However, keep in mind that such testing on HDDs or SSDs doesn't tell you much. It only tells you that it worked at the time of the test, not that it is working now or in the future.

 

[Will Keir]

Thanks Jeff. SSD Software Raid 0 is up and operational, I'm not sure if I'm qualified to make a guide yet. Thanks for the tools.