FORUMS: list search recent posts

RAID level reliability

COW Forums : Storage & Archiving

VIEW ALL   •   PRINT   •   NEXT >>
Alex Gerulaitis
RAID level reliability
on May 21, 2013 at 1:49:31 am

What's the most reliable RAID level, and why? (Let's forget performance considerations for the purpose of this thread.)

The factors affecting reliability are drive FR (failure rate), and UREs. Reliability is minimizing chances of data loss, which seems to be not a single factor either: (1) minimized chances of catastrophic data loss, (2) minimized chances of smaller data loss incidents (corrupted files). Then there's also maximized uptime - not sure where that fits in.

I've seen papers on RAID5 vs. RAID6, triple-mirroring RAID1, but not RAID10 vs. RAID6. The latter two seem to be discussed the most in terms of reliability.

(As there isn't a "storage" forum on Cow, I figured my best chance of getting a good discussion started is in this forum.)

Thanks in advance for any ideas.

Alex Gerulaitis
Systems Engineer
DV411 - Los Angeles, CA


Return to posts index

alex gardiner
Re: RAID level reliability
on May 21, 2013 at 8:55:04 am

+1 This a good discussion Alex and I'm pleased you raised it, as it is of interest to me too.

While you say forget performance, (as you know) it is always a requirement to consider the application alongside utilization and reliability? After all, of the three, its usually only possible to pick 2 ;)

Turning it on its head, we may avoid failure, but end up with a system that is unreliable from a usability perspective.

In turn, if we are forgetting performance all together, would we consider technologies such as RAIDZ? Removing the controller itself might not be the worst idea?

NB: Since the cow is a rather flame prone, I'll temper this statement by saying that IMO Z is not particularly practical for post storage in 2013.

Like you I've read the papers (and then some) and my view has become one of avoiding raid5 for larger units (shoot me - I'm not selling anything).

Ahem.. so, without really contributing anything at all, I'll simply say that I am also looking forward to some real input and figures from the big players. Will they share... I hope so :)

Alex

--
+447961751453
indiestor.com
github.com/indiestor/


Return to posts index

David Gagne
Re: RAID level reliability
on May 21, 2013 at 2:51:27 pm

A multi mirror raidz would be most resiliant to drive failure. Add in HA, UPS, and it's never going down...


Return to posts index


Alex Gerulaitis
Re: RAID level reliability
on May 21, 2013 at 6:50:23 pm

[David Gagne] "A multi mirror raidz would be most resiliant to drive failure. Add in HA, UPS, and it's never going down..."

Thanks David. Not familiar with Z although I heard good things about it. Are there any models that quantify that resiliency, and measure it against, say, 10, 6, and a 3-way RAID1, in a similar way Adam Leventhal does it with 5 and 6?

(I realize copying the same data in at least three places is the most resilient method - and RAID6 might be the most efficient implementation of it in terms of space utilization - even if not the most reliable.)

Wikipedia has an AFR formula supposedly measuring resiliency but I am not too happy with it: doesn't account for risks of UREs during rebuilds; factors annual FR rather than the risk of simultaneous failures within drive replacement and rebuild time frames.


Return to posts index

David Gagne
Re: RAID level reliability
on May 21, 2013 at 7:51:53 pm

In terms of resiliancy, it's not a hard math problem.

Raid6, you have two drives that can fail without loss. Raid10 is a RAID0 (stripe) across RAID1 (mirror) sets. In this you can have 1 drive failure from any of the sets without loss, but if both drives fail in a set simultaneously, you have loss. But to quote someone I know, "I've never had drives fail faster than I can replace them one at a time." If you have RAID5, and a drive fails, and you replace it same day, you will not lose data.

But lets say you are the most paranoid person on earth. You could take 16 disks and do 3 sets of RAIDZ3 and mirror them. This would give you the ability to lose 3 disks per set, or up to 2 whole sets and 2 disks on your existing set, and still rebuild. Of course you'd only get 2 disks worth of storage with this scheme, but YOU ARE LIVING SCARED. Basically as long as you had 2 good disks in the same set, your data would be secure.

Oh, but of course, you have a backup on tape, right?


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 21, 2013 at 8:22:55 pm

[David Gagne] "If you have RAID5, and a drive fails, and you replace it same day, you will not lose data. "

You might if you get a drive failure or an URE during rebuild - which is technically after replacement. Chances of an URE (non-catastrophic data loss) during rebuild are higher than 50% on a 10TB array with desktop drives - if we believe published URE numbers - which some people think are too optimistic.

Single bit URE on video files - may not be a big deal. In Pentagon - it probably is - they wouldn't want that drone send a Hellfire to the wrong address...

So RAID5 is fine in many circumstances but it can no longer be considered truly resilient with today's high capacity drives. On top of it, we don't really know what happens on that near-certain URE-on-rebuild: will the RAID brain offline the drive and fail the whole array? That would mean a near-certain catastrophic data loss on a whole array with a single drive failure. Or will it just leave that URE in place meaning a single bit error in your file or file system? Either way - not pretty.

RAID6 is quite a bit more resilient, both with UREs and drive failures as chances of two or three happening within the same replacement / rebuild cycles are much, much smaller. RAID10 is also resilient to multiple drive failures and to a lesser degree - with UREs.

I just wanted to see if anyone had a math model or stats pitching 6 against 10 but it may indeed be an exercise in vain.


Return to posts index


Vadim Carter
Re: RAID level reliability
on May 23, 2013 at 4:08:19 pm

It is true that RAID 6 can sustain a loss of any two drives in a set. RAID 10, however, can lose more than two drives and still remain operational. This is because RAID 10 stripes on top of multiple mirrored pairs of disks and for as long as there is at least one good disk in each mirrored pair, RAID 10 will stay operational.

I do have all the nitty-gritty details and formulas laying around somewhere which explain mathematically which RAID level is more reliable. If my memory is correct, RAID 10 is deemed slightly more reliable than RAID 6.

Earlier threads had a statement about minimizing chances of data corruption. To anyone reading this, make no mistake about it, RAID does not protect against data corruption. Furthermore, as disk drives get larger in capacity, the probability of silent data corruption increases no matter what RAID Level is used. This is why RAIDZ is an excellent choice where data integrity is paramount, each block of data is checksummed and the checksum is then written to a separate area of the disk with a pointer to the original data block. The pointer itself is also checksummed. When a data block is accessed, its checksum is checked and verified thus guaranteeing immediate corruption detection.

One last thing in regard to performance, all other things being equal, RAID 10 will always outperform RAID 6. The reason is simple - parity calculation is an "expensive" operation. Calculating it twice is even more "expensive".

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 23, 2013 at 9:12:29 pm

Thanks for the input Vadim.

[Vadim Carter] "I do have all the nitty-gritty details and formulas laying around somewhere which explain mathematically which RAID level is more reliable. If my memory is correct, RAID 10 is deemed slightly more reliable than RAID 6."

Would be awesome if you could find those formulas and see if they account for all the reliability variables and factors:
- chances of enough simultaneous drives failures within a rebuild cycle to bring down the whole array
- UREs and how they affect reliability, especially during rebuilds
- protection against other causes of data loss

From my research so far, reliability advantages of either RAID level depend on a balance of drives' FR and URE rates. E.g. if there is a guaranteed URE during a mirror rebuild, then there is a guaranteed data loss incident in RAID10. 6 OTOH will be resistant to it, as it still has another place where to look for healthy data during rebuilds.

Based on that alone, resistance of RAID6 to data loss due to UREs is much, much higher vs. RAID10 on a single drive failure - thousands to millions times so. Does it make RAID6 much more reliable overall? I don't know, and would love help with that.

At the same time, resistance to whole drive failure is really down to FR within drive replacement / rebuild window, not necessarily drive's lifetime - which may make Wikipedia and many other formulas not too trustworthy.

If we assume that there's an increased chance of a drive failure during rebuild (in the same mirror pair, or in RAID6 array), then RAID10 may have less of an advantage, depending on those chances.

This is why I think formulas will help play with failure and URE rates, and perhaps also match them to available stats.

[Vadim Carter] "To anyone reading this, make no mistake about it, RAID does not protect against data corruption."

Perhaps you're talking about "silent rot", not all incidents of data corruption? A URE is data corruption, and redundant RAIDs do protect against them, to a degree?

[Vadim Carter] "This is why RAIDZ is an excellent choice where data integrity is paramount, each block of data is checksummed and the checksum is then written to a separate area of the disk with a pointer to the original data block."

Are checksums a function of RAIDZ or ZFS?

[Vadim Carter] "One last thing in regard to performance, all other things being equal, RAID 10 will always outperform RAID 6. The reason is simple - parity calculation is an "expensive" operation. Calculating it twice is even more "expensive"."

Agreed, parity calculations are expensive - yet computing power grows much, much faster than disk speeds. Perhaps at some point parity calculations on beefy systems with software RAID will get cheap enough to have a negligible effect on performance if they haven't already? I'd be more concerned with I/O than parity overhead.


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 24, 2013 at 2:27:53 am

[Alex Gerulaitis] "This is why I think formulas will help play with failure and URE rates, and perhaps also match them to available stats."

Found a spreadsheet that seems to be doing exactly that, on zetta.net/_wp/?m=200906.

It puts RAID10 reliability at about 25% that of RAID6, with certain assumptions about drive counts, URE and failure rates. Not sure how trustworthy it is until someone more knowledgeable than me analyzes it.

(The page I linked to above has errors and may not be easily navigable depending on your browser. I put that spreadsheet and up on my GDrive if you'd like to take a look at it.)


Return to posts index


Vadim Carter
Re: RAID level reliability
on May 24, 2013 at 5:12:27 am

Alex, here are a couple of papers that I had saved as a reference a while ago that seem to support your assertion that RAID 6 is more reliable than RAID 10:

Microsoft Exchange Server 2007 and IBM
System Storage N series with RAID-DP Best practices


Disk failures in the real world:
What does an MTTF of 1,000,000 hours mean to you?


From a purely practical perspective, however, ever increasing drive sizes result in ever increasing rebuild times. On a moderately loaded array consisting of 16x4TB spindles in a RAID 6 configuration a drive rebuild can take over 24 hours. With 48x4TB drives, a rebuild of one drive can take days. Same drive configurations in a RAID 10 arrangement only take a few hours to rebuild with a lot less I/O load on the remaining array members. If MTTR of a degraded RAID set is measured in hours vs. being measured in days, it seems that the risk of data loss is less with RAID 10, IMHO.



[Alex Gerulaitis] "Perhaps you're talking about "silent rot", not all incidents of data corruption? A URE is data corruption, and redundant RAIDs do protect against them, to a degree?"

Unrecoverable Read Errors "could" cause data corruption. The idea is to detect them, flag them, and re-write the data to a different block before the damage is done (using checksums with RAIDZ or scheduled parity scrubs in a RAID 5 / RAID 6 array). What happens most often is that a drive fails and a rebuild starts; while a rebuild is taking place and due to heavy i/o, a few drives start throwing UREs and if there is just one or two UREs within the same stripe (assuming RAID 6) it goes okay but as soon as there are three UREs within the same stripe - there is data corruption. I have seen it occur a few times. A disproportionately large number of data corruption cases however is due to some sort of filesystem corruption - an OS-level problem that a RAID cannot protect against.




[Alex Gerulaitis] "Are checksums a function of RAIDZ or ZFS?"

They are a ZFS feature. So, just to clarify:

RAIDZ = RAID 5 as implemented in ZFS
RAIDZ2 = RAID 6, two-dimensional parity, as implemented in ZFS
RAIDZ3 = no traditional RAID level, triple parity, as implemented in ZFS

ZFS also supports striping (RAID 0), mirroring (RAID 1), as well as double and triple mirrors. Checksums are supported regardless of the RAID Level being used.


[Alex Gerulaitis] "Agreed, parity calculations are expensive - yet computing power grows much, much faster than disk speeds. Perhaps at some point parity calculations on beefy systems with software RAID will get cheap enough to have a negligible effect on performance if they haven't already? I'd be more concerned with I/O than parity overhead."

That's why I said "all other things being equal". Most modern hardware already has more than enough of spare CPU capacity to do parity calculations and can have far more RAM and cache than an embedded hardware RAID controller.

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 24, 2013 at 7:59:33 pm

[Vadim Carter] "Alex, here are a couple of papers that I had saved as a reference a while ago that seem to support your assertion that RAID 6 is more reliable than RAID 10"

Thanks Vadim. Couldn't quite grasp the math on the first attempt, but I'll try again, perhaps with a double espresso this time.

[Vadim Carter] "With 48x4TB drives, a rebuild of one drive can take days."

I am hoping nobody does those really wide parity groups without understanding the implications. Personally, I'd do RAID60 on 48-wide group.

[Vadim Carter] "Same drive configurations in a RAID 10 arrangement only take a few hours to rebuild with a lot less I/O load on the remaining array members."

No contest your honor, but there's still that pesky URE probability during rebuilds, that can only be addressed by using triple mirroring in RAID10. So where short rebuild times and/or stable high performance are required (vs. higher reliability), RAID10 is a viable option.

[Vadim Carter] "as soon as there are three UREs within the same stripe - there is data corruption. I have seen it occur a few times."

That's pretty amazing (that you've seen it) given how low the chances of that are based on published URE rates.

Thanks again Vadim.


Return to posts index

Vadim Carter
Re: RAID level reliability
on May 25, 2013 at 1:02:47 am

[Alex Gerulaitis] "I am hoping nobody does those really wide parity groups without understanding the implications. Personally, I'd do RAID60 on 48-wide group."

You'd be surprised, Alex, how many installations do have those very large RAID sets... I concur - RAID 60 is the right way to do it.

I have briefly looked at the spreadsheet you found and it looks intriguing. I am not an Excel ninja and I cannot attest to the accuracy of the formulas being used. I'll play with the numbers and try to trace the logic behind all the variables being used. It is certainly a good find and we can build on that :) Thanks, Alex.

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 21, 2013 at 6:37:23 pm

[alex gardiner] "While you say forget performance, (as you know) it is always a requirement to consider the application alongside utilization and reliability?"

Thanks Alex. You're right, performance is always a factor, as is efficiency (ratio of performance and usable capacity to TCO).

My personal quest in this is to figure out which one is more reliable - 6 or 10, and why, using good math models supported by stats. RAIDZ - for me personally - falls outside of it as it's not supported by popular RAID controllers I use. That said, I am not opposed to discussing it.

[alex gardiner] "In turn, if we are forgetting performance all together, would we consider technologies such as RAIDZ? Removing the controller itself might not be the worst idea?"

Just for the purpose of this thread, I'd like to center on a perhaps quite theoretical question of what industry standard RAID level is the most reliable - along with why and by how much.


Return to posts index

Bob Zelin
Re: RAID level reliability
on May 21, 2013 at 10:16:58 pm

no matter what is determined from this thread, everything fails, there will always be data corruption at the worst possible time. If you do not have a secondary method of backup (with drives) or archive (with LTO) you are playing Russian roulette with your media. I try to use RAID 6 as often as possible these days, but data corruption is a fact of life, and programs like Disk Warrior do not always solve these issues. You MUST have a backup plan, no matter what the most reliable RAID level is.

just my 2 cents.

Bob Zelin



Return to posts index

Eric Hansen
Re: RAID level reliability
on May 27, 2013 at 6:06:47 pm

David said "But to quote someone I know, "I've never had drives fail faster than I can replace them one at a time." If you have RAID5, and a drive fails, and you replace it same day, you will not lose data."

I HAVE lost a drive while a drive was rebuilding in a RAID5 set. After that near heart attack (ATTO tech support helped me recover the RAID) I only do RAID6. When I do have a drive failure and a rebuild begins, I try to get the editors to not use that volume if at all possible. it speeds up the rebuild and reduces the chance of corruption.

I hadn't thought of RAID60 for larger sets. None of my current volumes goes over 16 drives. But I'm gonna have to look into that very soon for some new 10GbE buildouts. I need more speed!

I am also very much looking forward to ZFS. the ability to expand a volume without reformatting is another awesome feature.

I agree with Bob that RAID level is only one variable in creating a reliable system. You have to look at all single points of failure. this is the main thing I hate about ethernet-based SANs vs FC-based SANs. The Xsans i built had multiple MDCs, multiple switches, multi-path FC controllers, 2 FC connections to every client, multiple power supplies on everything, etc. But the scope of this thread is limited to RAID level, so i digress.

e

Eric Hansen
Production Workflow Designer / Consultant / Colorist / DIT
http://www.erichansen.tv


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 27, 2013 at 8:01:22 pm

[Eric Hansen] "the ability to expand a volume without reformatting is another awesome feature."

I've done this with RAID5 and RAID6 volumes. Am I missing something? (Thought ZFS's advantages were centered around resiliency, performance, integration with RAID-Z.)

[Eric Hansen] "this is the main thing I hate about ethernet-based SANs vs FC-based SANs"

Eric, would you elaborate on this?

My understanding was that layer 3 Ethernet switches could do auto-failover, something that's not part of FC where failover is handled primarily on the driver or even ASIC level - but is not part of the "intelligence" of the protocol.


Return to posts index

Eric Hansen
Re: RAID level reliability
on May 27, 2013 at 8:47:01 pm

[Alex Gerulaitis] "[Eric Hansen] "this is the main thing I hate about ethernet-based SANs vs FC-based SANs"

Eric, would you elaborate on this?

My understanding was that layer 3 Ethernet switches could do auto-failover, something that's not part of FC where failover is handled primarily on the driver or even ASIC level - but is not part of the "intelligence" of the protocol."


Alex, you definitely trump me here, and i don't want to hijack the thread. from what I understand, FC can failover because OS X can understand multi-pathing over FC (i might be getting the terminology way wrong here). if you have a RAID with redundant FC controllers going into multiple FC switches (for redundancy), the client computer can understand that. it won't mount the volume twice even though it can "see" 2 paths to the same volume. if one path disappears, the client system won't freak out.

I've actually never had an ethernet switch fail over its useful life, so i'm not too worried about that. AFP-based Ethernet systems use a single server (no MDC), ethernet cards, and direct attached storage (through a single card). if anything in that chain fails (the server, the SAS card in the server, the ethernet card, the SAS expander on the SAS RAID), the client loses connection to the storage. with FC, all of these things can be redundant if you set them up that way.

if i need to work on the AFP server, i can't just make it failover to a backup and then take it offline like I could with Xsan.

so this is more NAS vs a true FC SAN setup. I prefer the latter for 24/7 critical systems and it's too bad that the growth of shared storage systems has been primarily on the NAS side than the SAN side.

Eric Hansen
Production Workflow Designer / Consultant / Colorist / DIT
http://www.erichansen.tv


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 27, 2013 at 9:50:15 pm

[Eric Hansen] "Alex, you definitely trump me here, and i don't want to hijack the thread. from what I understand, FC can failover because OS X can understand multi-pathing over FC"

I am a n00b in FC or Ethernet failover, all I did was a little reading and a couple of training sessions on a high-end iSCSI based SAN. So this is a very useful discussion for me.

No worries about thread hi-jacking - with Vadim's help, RAID6 emerged as the winner in terms of reliability. So the thread is more or less done with. Appreciate your concern though - perhaps fork this into a new thread? Something like, "Ethernet vs. FC - which is more resilient?"


Return to posts index

Vadim Carter
Re: RAID level reliability
on May 30, 2013 at 2:29:05 am

"[Eric Hansen] "the ability to expand a volume without reformatting is another awesome feature."

[Alex Gerulaitis] I've done this with RAID5 and RAID6 volumes. Am I missing something? (Thought ZFS's advantages were centered around resiliency, performance, integration with RAID-Z.)"


I'll try to explain and put my 2c in.

A traditional hardware controller based RAID array will typically allow RAID5 or RAID6 expansion by restriping a RAID set to include any newly added drive(s) (an inherently dangerous operation). The end result is an increase in the RAID Set size, however, the filesystem size that is residing on the newly expanded RAID set is still the same. There are three options at this point: 1. "Stretch" the existing filesystem over this newly added space, if your OS supports this; or 2. Create a second partition on this newly added space, format, and mount; or 3. Delete everything, reformat, create new filesystem, mount.

ZFS is a filesystem and a volume manager "all in one" so to speak. Adding additional drives is a very simple operation. There is no need to wait for ZFS RAID Set to restripe. There is no reformatting involved. There is no risk to the data. It just works. Like magic.

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 31, 2013 at 12:45:37 am

[Vadim Carter] "There is no need to wait for ZFS RAID Set to restripe. There is no reformatting involved. There is no risk to the data. It just works. Like magic."

I could see how "no reformatting" works (legacy RAID expansions also don't require reformatting) but no re-striping? Say, you added another eight drives to an existing set of eight in RAID-Z - how would the performance (transfer rates) of existing files improve w/o re-striping?


Return to posts index

Vadim Carter
Re: RAID level reliability
on May 31, 2013 at 2:15:26 am

[Alex Gerulaitis] "I could see how "no reformatting" works (legacy RAID expansions also don't require reformatting) but no re-striping? Say, you added another eight drives to an existing set of eight in RAID-Z - how would the performance (transfer rates) of existing files improve w/o re-striping?"

This is another cool thing about ZFS - the whole concept of storage pools. ZFS storage pools can span multiple vdevs (virtual devices), and vdevs themselves consist of block devices, e.g. hard drives or partitions on these hard drives. So, what would happen in the example you gave above is that a second RAID-Z vdev will be created of eight drives and the original RAID-Z vdev and the new RAID-Z vdev will be pooled.

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on May 31, 2013 at 2:36:47 am

[Vadim Carter] "ZFS storage pools can span multiple vdevs (virtual devices)"

Vadim, I was talking about how the width of a stripe affects performance. Can't improve performance without widening a stripe one way or the other, correct? I.e. even in RAIDZ, you'd have to re-stripe the array to improve performance. (At least that's my understanding.)


Return to posts index

Vadim Carter
Re: RAID level reliability
on Jun 1, 2013 at 3:03:58 am

[Alex Gerulaitis] "Vadim, I was talking about how the width of a stripe affects performance. Can't improve performance without widening a stripe one way or the other, correct? I.e. even in RAIDZ, you'd have to re-stripe the array to improve performance. (At least that's my understanding.)"

There are a few ways to improve performance, and, you are correct, Alex, by increasing the stripe width or, simply put, striping across more disk spindles thus taking advantage of parallelism. When you expand a ZFS pool, ZFS uses dynamic striping in order to maximize throughput and attempts to include all devices in order to balance it.

Below is a quote from Oracle:

"ZFS dynamically stripes data across all top-level virtual devices. The decision about where to place data is done at write time, so no fixed-width stripes are created at allocation time.

When new virtual devices are added to a pool, ZFS gradually allocates data to the new device in order to maintain performance and disk space allocation policies. Each virtual device can also be a mirror or a RAID-Z device that contains other disk devices or files. This configuration gives you flexibility in controlling the fault characteristics of your pool. For example, you could create the following configurations out of four disks:

-Four disks using dynamic striping

-One four-way RAID-Z configuration

-Two two-way mirrors using dynamic striping

Although ZFS supports combining different types of virtual devices within the same pool, avoid this practice. For example, you can create a pool with a two-way mirror and a three-way RAID-Z configuration. However, your fault tolerance is as good as your worst virtual device, RAID-Z in this case. A best practice is to use top-level virtual devices of the same type with the same redundancy level in each device."

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Andreas Aanerud
Re: RAID level reliability
on Jun 16, 2013 at 3:20:09 pm

At our house , I have tested a lot on a "simple" 12 bay shelf, with a Dell H800 hw raid card (Level 5, 6 10, 50 and 5 + 5 mirror) , and now i have used LSI 9211-8i to also test ZFS and i have to say, im deeply impressed.

There is a lot of hard geeking to do, but if u sett it up right, you will gain a lot of performance, and zfs has some other cool features. like nfs sharing built in the file system, and compression, and as mentioned checksums, on the comercial front you have "NexentraStor" (OpenIndiana / SUN) and "ixsystems" (Freenas / FreeBSD) , you also have, napp-it a pluggin for a lot of systems, but that runs best on Omni-OS

I think i have used over a year now for testing, and we landed on FreeBSD 9.1 with Freenas (with comercial support from ixsystems)

Some interesting links that i have picked up ower the year.

http://hansdeleenheer.blogspot.no/2012/07/nexenta-scale-and-cluster.html
https://calomel.org/zfs_raid_speed_capacity.html
http://catn.com/2012/05/11/openindiana-vs-nexentastor-vs-freenas/
http://www.zfsbuild.com/2013/01/25/zfsbuild2012-nexenta-vs-freenas-vs-zfsgu...

Best "old" video explaining zfs






Return to posts index

Vadim Carter
Re: RAID level reliability
on Jun 26, 2013 at 2:17:38 pm

Thanks for your post, Andreas. It is nice to get an independent endorsement from a person using RAIDz/zfs in production. While there are still many users who are completely unaware of the benefits zfs-based storage brings to the table, I believe the tide has turned and we'll see more people jumping aboard.

Lucid Technology, Inc. / 801 West Bay Dr. Suite 465 / Largo, FL 33770
"Enterprise Data Storage for Everyone!"
Ph.: 727-487-2430
http://www.lucidti.com


Return to posts index

Alex Gerulaitis
Re: RAID level reliability
on Jul 3, 2013 at 9:38:03 pm

[Andreas Aanerud] "There is a lot of hard geeking to do, but if u sett it up right, you will gain a lot of performance"

I would love to hear about that "lot of hard geeking", and why it's necessary, how users deal with and react to the lack of online array expansion, the fact that ZFS only applies to NAS boxes (not DAS or SAN storage), and about ZFS performance benefits.

Yet since this is a thread dedicated purely to RAID level reliability, then perhaps we could fork ZFS-related discussions to a different thread on Cow's NAS forum?


Return to posts index

VIEW ALL   •   PRINT   •   NEXT >>
© 2020 CreativeCOW.net All Rights Reserved
[TOP]