I purchased an ARC 1200 and I'm going to set up a RAID 0 Parity and a Raid 1 Cache ala WeeboTech, but I have a few questions.

 

Do I need to clear the drives before setting up the Raid 0 partition or after or will the hardware take care of this? I assume UnRaid is smart enough to rebuild the Parity once I put the new drive in the right device slot?

 

Anything else to consider?

What are you hoping to accomplish by setting your parity on RAID0?

Perhaps I misunderstand the intention, but wouldn't it make more sense to have a Raid 1 parity (so you have dual parity) and a Raid 0 cache (since it's fast, and cache lacks redundancy by design anyway)?

That's why I asked what his goals are. To me it doesn't make sense to configure RAID0 for either application. I don't think the performance gain is worth the increased risk of data loss.

RAID 0 parity should speed up writes without reducing reliability. The system can still operate with the loss of a single drive (or even both parity drives).

 

RAID 1 cache would provide the same reliability to the cache drive. But, with RAID 0 parity you should not need a cache.

Write operations and parity calculations depend on the speed of not only the parity drive, but also of EVERY drive in the array. RAID0 WILL affect the reliability of the parity drive, because if either fails, it means a rebuild. RAID0 has data striped across both disks, so a failure of either means a failure of the RAID0 array as a whole. This essentially doubles the chance of a failure of the parity drive, which I think is unconscionable in a situation where you're looking for data redundancy. If someone has data to demonstrate that a RAID0 parity on unRAID will significantly improve write performance and/or parity calculations, I'd love to see it.

 

In my opinion, RAID0 should only be used in gaming PCs, where performance is at a premium, and even then I'd recommend frequent image backups of the array. If someone is after good write performance and are willing to sacrifice data integrity, then they should probably build a RAID5 server instead.

 

I don't understand this fascination with write speed anyway. How much data are you guys writing to your server, anyway? I'm in the midst of ripping and moving DVDs now that my server is running reliably, and even so I'm only moving 20-40 GB at a time, every few days. I use Teracopy, allow it to do its thing in the background, and get other stuff done. If I couldn't stand it, I'd install a cache drive, which would more or less double my speeds. But really, how fast does it need to go? And why on Earth would you risk your data integrity to get there?

 

 

RAID 0 parity will allow multiple concurrent writes at decent speed. The chance of drive failure is increased by a single drive. The chance of data loss is not increased significantly. Applications which require multiple concurrent writes should benefit from RAID 0 parity.

 

One new parity drive is required for each additional concurrent write to a discrete data drive. At the extreme, economically this is RAID 1, performance is the same and reliability is slightly improved over RAID 1 . If a small number of concurrent writes are required then RAID 0 parity should help.

And how often do you need to do multiple concurrent writes? The drive failure rate is increased by one drive across the entire array, but doubled for the parity drive. Why increase the failure rate AT ALL for what is presumably a low percentage situation.

 

And now you've gone from stating that a RAID0 parity will increase write performance to the point where you don't need a cache drive, to stating that it should help with multiple concurrent writes. Since file copying is a linear operation, you'd need to be copying/moving files from multiple locations, or running multiple file copy/move operations from the same computer in order to get any performance difference. Again: how much data are you moving to the server to justify ANY reduction in data integrity?

 

You are of course free to do whatever you wish, but I consider it an unacceptable risk for a machine whose sole purpose is to maintain data integrity.

I have an application that requires multiple concurrent writes. The doubling of the chance of parity drive failure is not significant to data safety. It does not matter how many parity drives fail concurrently. The array continues to operate, the failed parity drives are replaced, and parity calculation ensues.

 

Parity drive size is inversely proportional to the number of parity drives. Smaller drives are cheaper and faster.

RAID-0 for parity may have a small postive impact on performance.  And would allow you to have a larger parity drive.  One issue with this, however, is that spin down does not typically work.

 

RAID-1 for cache makes a ton of sense.  I have been advocating an enhancement to unRAID to allow a RAID-1 pair in parallel with the unRAID array.  Problem with hardware RAID-1 is that if the motherboard/controller were to fail, the ability to find a replacement that will recognize the RAID-1 pair is not guaranteed.  And same issue with spindown.

For others looking for more info, look for WeeboTech's posts on using a SAFE33 system to provide for a RAID-1 Cache drive and RAID-0 Parity drive by using the same controller with two drives.

 

As for the drives you're going to use, I'd run each through their own preclear activity to make sure they're in operation shape. Then after that, connect them together on the raid controller and configure them for your RAID-1 and RAID-0 drives, then let unRAID deal with creation of the Cache and Parity drives.

Spin down of raid sets on the ARC controller is handled within the ARC controller.

Parity and Cache DO SPIN DOWN. There is a setting in the bios. I think mine is at 1hr.

 

Coming late to this thread. There's allot said here.

I think the only time there's an issue of reduced data redundancy is if you have a failed drive and you do not have an onsite spare.

 

My drives are all fairly recent.. 1tb and larger. I have a spare 2TB drive just sitting there precleared for emergency.

I have 2 1.5tb drives in the RAID0/RAID1 Safe configuration.

Worst case, I rebuild parity onto the 2TB.

 

Now about the "how often do you need fast writes" line of thought.

In my case, I had a large machine, every drive was RAID1. I have a number of smaller machines. Each with it's own or multiple RAID1 sets.  So by consolidating all drives into the master unRAID server I've reduced spindles and increased my space.  What I needed after that was fast safe writes over NFS.

So the RAID1 cache has a hidden directory for remote NFS /home mounts.

 

This lets me keep 3 drives spinning all day long instead of 8 drives in 4 machines spinning all day long.

 

RAID1/RAID0 set of 2. and one unRAID drive that I use as a repository for all downloads.

My other adminstrative servers were set up to use a SSD for the OS and remote NFS for /home or src archival mounts.

 

Works for me. Am I concerned about reduced protection. No.

not only do I have RAID1 for the critical files, I rsync them frequently to a special rsync-linked-dest directory structure on the unRAID array. backups of backups.

 

I do like to have fast writes. When I develop in the vmware slackware environment with the remote NFS, I want it to be as fast as possible.

Also moving data from my ripping machine to the unRAID server occurs at somewhere from 30-55MB/s depending on other simultaneous operations.

 

There has also been comments about the Cache in the ARC controllers.

Since I have a UPS I'm not really that afraid of the situation. The only time it may come into play is if I were doing a parity generate.

For me that operation is pretty fast considering I have 20 drives 1TB and up.

Plus I do it on a monthly basis.

Nov  2 09:51:24 atlas kernel: md: sync done. time=34928sec rate=61482K/sec

 

My design is X7SBE, 2 SATA2 MV8's each on a separate 100MHZ PCI-X bus, 5 drives on each controller, 6 drives on motherboard, 5 drives on an areca PCI-E controller.

The 6th drive is an SSD on a PCI slot rafter.

I do have the ability to add up to 20 more drives via external eSATA via a PCI-X card using PMP, but I do not use them at this time.

 

Push comes to shove, I'm sure I'll be fine.

Thanks for the additional info guys. It sounds like both Weebotech and dgaschk have specific needs for the faster write speeds, and have the knowledge and equipment necessary in the event of a drive failure. I'm just leery of someone with relatively little experience doing this, and I wanted to make sure the OP had his ducks in order.

 

@WeeboTech: "I have 2 1.5tb drives in the RAID0/RAID1 Safe configuration."

Can you elaborate on what you mean by safe configuration? Do you mean RAID10, a.k.a. RAID1+0? I thought you needed four drives for that?

 

@WeeboTech: "I have 2 1.5tb drives in the RAID0/RAID1 Safe configuration."

Can you elaborate on what you mean by safe configuration? Do you mean RAID10, a.k.a. RAID1+0? I thought you needed four drives for that?

 

It's more like a SAFE25 configuration.

In any case doing a search on SAFE33/SAFE50 may yeild better explanations.

In my terms.

 

The drives are combined in a manner where part of the 2 drive pair 75% is used in a RAID0 configuration.

This yeilds a virtual drive of 2TB (in my configuration with 2 1.5TB drives).

The rest of the drive cylinders are used in RAID1 (safe) configuration. In my configuration this yeilds 350GB.

 

So 2 1.5 tb drives yeild 1 virtual drive of 2TB in RAID0 and 1 virtual drive in RAID1 of 350GB.

If a drive dies, the RAID0 array is no good, but the  RAID1 array is still available.

 

ATM my ducks are on the ground, as the machine won't boot with the ARC-1200 in there. I was able to set up the Raid set and volumes and initialize them, but the machine hangs before it boots. I can't get into the MB BIOS anymore either, so it could be a setting or a poorly seated card; it's definitely a tight squeeze.

 

Board is an A8N SLI Premium, which I have seen others use. I left a message with Tech Support and I'm waiting to hear back. I'll pull the controller again and play with BIOS. I guess Iill put it in another machine on the weekend, just to make sure it's not the controller. I've also got a better board, but I was saving that for a higher calling.

 

 

 

 

Hmm, as I recall, that board uses the NForce4 chipset, which I seem to remember warnings about this chipset causing data corruption. Does anyone have anything concrete on that?

Hmm, as I recall, that board uses the NForce4 chipset, which I seem to remember warnings about this chipset causing data corruption. Does anyone have anything concrete on that?

 

Thanks for the effort Kenoka,

 

I plugged another MB into the Power Supply on the case temporarily and it boots up with the ARC-1200 installed. The FW seems a little slow to load and it says it does not see any devices when it loads, but I suspect that's because they are not active? I wanted to change the size of my Parity volume anyway, as 1.5TB comes in at a little less than 1.5. I doubt this is an issue, but I did not want UnRaid complaining about the Parity disk being too small. It's initializing the disks again now. I could not boot to floppy on the other MB; I guess the BIOS is corrupt, as the RTC was losing time. I replaced the battery, but that did not solve my boot issues. Maybe clearing the flash will fix the problem.