PDA

View Full Version : Pros/cons of Concatenated Software Raid


blubbernaut
01-05-2006, 11:05 PM
Have just upgraded the internal drives of a couple of G4 towers and while wondering what to do with the original 30 and 40Gb drives, thought about using Tiger's built in RAID options to add that capacity to the new drives so as to appear as one larger drive.

Note I'm not talking about mirrored or striped RAID options here.

I'm wondering if there are any performance or compatibility cons to this kind of software RAID? I would have thought that it'd be less overhead than mirrored as it might only read/write to the second drive when capacity is reached on the first??? Discuss... ;)

giskard22
01-05-2006, 11:34 PM
I think that's a pretty bad idea. When you have JBOD or striping and a single mechanism fails, the entire volume is destroyed. The dangers of data loss are likely to outweigh the addition of a measly 30 or 40 GB to your boot volume. For most people, it wouldn't really be much less convenient to just have them available separately. Given how old those drives probably are, you'd practically be begging for a failure.

Also, if you have a second volume in each machine you have a convenient way of making an emergency startup disk, a quick backup location, etc.

Generally, software RAID is only wise if you 1) need large amounts of scratch space with no data protection or 2) are using mirroring to provide a layer of protection against down time.

blubbernaut
01-06-2006, 09:37 PM
That's a pretty decent argument right there. I think you're right. I hadn't realised that the system would of course be constantly spanning files over the two disks and not just saving individual/discreet files to the second disk when needed. The loss of the older disk affecting the whole is not an acceptable risk for anyone really!

Cheers.

barryjaylevine
01-07-2006, 09:30 PM
I used Disk Utility in Tiger to RAID (concatenate) two 300GB drives together. They are both in one enclosure (PATA to FireWire). They've been working fine. However, this afternoon I discovered that a PowerBook running Panther couldn't see the concatenated disk. The PB responded that the device "contained no mountable volumes" (or something like that). Is this normal? Is such a RAID compatible with Tiger only?

giskard22
01-08-2006, 02:00 AM
I believe that 10.4 did change how RAIDs are created/formatted/whatever, and your volume is probably not backwards-compatible. Your test is pretty good initial evidence of this, though it would help to have another 10.3 machine to verify with.

Sumleilmus
07-29-2006, 10:47 PM
I just found this thread, and there are VERY few threads that a search for "concatenated" finds.

According to wikipedia (no flame wars, please), http://en.wikipedia.org/wiki/RAID_5#Concatenation_.28JBOD.29 , "One advantage JBOD has over RAID 0 is in the case of drive failure. Whereas in RAID 0, failure of a single drive will usually result in the loss of all data in the array, in a JBOD array only the data on the affected drive is lost, and the data on surviving drives will remain readable. However, JBOD does not carry the performance benefits which are associated with RAID 0."

That seems to contradict what is said above.

Is there anyone who has EXPERIENCE (not the same thing as opinions, which seem to strangle the life out of many discussions of RAID and things similar to RAID if not exactly RAID) with Tiger's "concatenated RAID set" option?

Especially, is the wikipedia claim that only the data on the failed drive is lost true with the Mac OS X 10.4 implementation of software RAID?

OK. Choke me.

But thanks.

barryjaylevine
07-30-2006, 09:58 AM
Yes; see my post of 1-8-06. Tiger's RAID is not compatible with Panther. This made my "set of two drives" (in one external enclosure) useless when attempting to use it with machines running 10.3.x.

Sumleilmus
07-30-2006, 10:41 AM
When you have JBOD or striping and a single mechanism fails, the entire volume is destroyed.

giskard22, what is your basis for this claim? There are differences between software RAID (or CDS - Concatenated Disk Set, a.k.a., JBOD) and hardware RAID, or at least so the authors of the Raid on Linux book on my shelf contend. The Mac OS X implementation of RAID ( & CDS/JBOD) is a software implementation.

Is only the data on the failed DRIVE lost (as wikipedia says) or is it as you say above?

barryjaylevine, thanks, but I read the entire thread. All the machines that will network to this proposed volume are OS X 10.4.5 or higher, or Windows.

JDV
07-30-2006, 01:45 PM
and therefore when the OS writes files, it does not always (in fact, generally does not) write them in a single block or set of blocks. Therefore, if the files in question are spread over two physical drives and one of the drives fails, the parts of the files on the failed drives are lost...which is the same as losing the whole file. THAT is why it has inherent risk. And yes, I can say that from experience (though not with a Mac system, I admit). In Novell server environments, it was common to span disks to create larger volumes, but the danger in this was duly noted by Novell. It is therefore extremely important to be sure that adequate backup is done. It isn't that the data can't be recovered from a backup. It's just that you've got a somewhat greater chance of actually needing it.

Joe VanZandt

barryjaylevine
07-30-2006, 03:11 PM
{snip} All the machines that will network to this proposed volume are OS X 10.4.5 or higher, or Windows.

I suspect that networking to the Mac that is hosting the JBOD will eliminate the "not-compatible-with-Panther" issue just as networking to a PC with an NTFS-formatted HD will also permit read/write access to Jaguar, Panther, and Tiger users.

Sumleilmus
07-31-2006, 10:25 AM
We made a test set of "Concatenated Disks" using USB flash memory devices (because they were nearby, and small).

We wrote files to them, and watched the activity indicator on each disk. The first volume in the set was the only one to show activity at the beginning of the write operation. Then it stopped, and the second drive began to show activity, then we saw the same for the third.

Removing one of the parts made the entire set unusable, and we could not, with our limited resources (DiskUtility 10.5 and DiskWarrior 3.03) recover any of the data.

Someone updated the wikipedia discussion re this, as it now stresses the differences between hardware and software implementations of this implementation of "RAID."

Essentially no documentation beyond the Help for DiskUtility is to be found at Apple.

It strikes me as odd that the disks would fill sequentially in this manner and yet the data would not be recoverable from the unfaulted disks in the set. I wonder if, as noted above, the Novell implementation wrote to the array more or less as though it were striped.

JDV, thanks. I don't claim that by watching the activity lights we could have been certain that no data was written to disks 2 or 3 while much data was written to disk 1.

I just document these things because they are empirical, and not arrived at by analogy.

So, in the Mac OS X 10.4 Concatenated Disk Set, if one disk fails, all the data is lost . . .

unless someone out there knows of a recovery tool to get it back.

JDV
07-31-2006, 02:20 PM
The advantage of spanning hard disk drives, and the reason you get a speed boost, is that you have twice (or n-times, where n is the number of disks) of read/write heads available to read and write data. And THAT is the reason that files may be spread across multiple disks, as well. Flash drives obviously behave rather differently than traditional hard disk drives. First, I'm not sure you'd see ANY speed difference in that case, so the advantage would be to simply span the drives into a larger drive. If you do that, the chances are that there is a database kept in the header of the first disk that TELLS it what disks are in the set and if the set is incomplete, that database doesn't function. Mind you, this is utter speculation on my part (not even as good as a poor analogy!), but it might explain the phenomenon you describe. To USE an analogy, tape backup systems used to use just such a system when backing up to multiple tape sets.

The bottom line for me is that RAID 0 isn't a very good idea in most cases.


Joe VanZandt

voldenuit
07-31-2006, 02:28 PM
We made a test set of "Concatenated Disks" using USB flash memory devices (because they were nearby, and small).
...
Removing one of the parts made the entire set unusable, and we could not, with our limited resources (DiskUtility 10.5 and DiskWarrior 3.03) recover any of the data.
...
Essentially no documentation beyond the Help for DiskUtility is to be found at Apple.

You may want to have a look at

man diskutil

in particular the part about RAID and how to replace failed disks.

bilbo--baggins
06-23-2011, 11:33 AM
You may want to have a look at

man diskutil

in particular the part about RAID and how to replace failed disks.

Sorry to dig up this old thread. I thought it was worth adding that Disk Utility Help now (in Snow Leopard) says

Be sure to back up your data frequently. If any one of the disks is damaged, you will lose the data thatís on all the disks.

kimboy
07-12-2011, 11:06 AM
I suspect that networking to the Mac that is hosting the JBOD will eliminate the "not-compatible-with-Panther" issue just as networking to a PC with an NTFS-formatted HD will also permit read/write access to Jaguar, Panther, and Tiger users.

acme.mail.order
07-12-2011, 06:53 PM
I've recently been experimenting with union mounts - if you need to add space to an existing full volume it appears to work in some instances. I prefer it over a JBOD set or concatenation as nothing needs to be reformatted.