Server:
I think clustered file system makes more sense, even if you keep 2 or 3 copies of the same data. Database can be kept on cluster also.
Google proved that this will work even with a lot of data and it can be done fast enough.

Now hopefully the software will get cheap enough to be used. Or Google might release their GFS as open source…

Desktop:
You should not keep your important data there anyways. So a RAID0 on SAS is pretty much all you can have there performance wise. (RAID 0 to see 3 SAS drives as 1 TB…)

In writing the above I was, I admit, thinking mostly about *file system* use of storage, where the existing lower-level storage interface actively impedes significant potential optimization (as ZFS helps illustrate) and where I see the most potential for dramatic improvement (given that the entire storage stack that lies beneath a file or object abstraction can be rethought).

However, even within the confines of that existing traditional block-level interface there are also possibilities for improvement, and products like Xiotech’s ‘Magnitude’ and perhaps also Compaq/HP’s ‘EVA’ have been exploring them for quite a few years now – primarily by replacing the traditional RAID static, algorithmic mapping between externally-visible logical array addresses and internal disk addresses with an explicit internal mapping that facilitates more flexible variation in numbers and sizes of disks and more flexible use of the space thereon – with considerably less management pain as well. For that matter, throw in HP’s innovative AutoRAID product from the ’90s as well, though AFAIK it never quite achieved the recognition that it might have (did its implementation fail to live up to its potential?).

I still think of such products as ‘RAID’ (well, perhaps ‘RAID V2.0′), but though they share a common abstraction (use of redundancy in the form of mirroring or parity across disks to achieve increased availability) they certainly don’t fit the 1988 definition at the detail level. Perhaps this is more what you had in mind (and I just stumbled upon an article from last month that may as well – http://searchstorage.techtarget.com/columnItem/0,294698,sid5_gci1246543,00.html).

- bill

RAID costs too much? When you can get mature open-source software implementations for free? Especially as I suspect that you’re just itching to discuss an alternative like ZFS, which is itself, of course, a software implementation…

Or perhaps you meant that *good hardware RAID implementations* cost too much. I think that Marc did an adequate job of defending their pricing – sophisticated NVRAM optimizations, rigorous drive-level and system-level testing, etc.

In anything resembling a free market, things *never* ‘cost too much’: they cost what they’re worth, or occasionally even less during market-share wars. If buyers didn’t feel that current hardware RAID products were worth what they cost, their prices would come down (there’s clearly at least some room for them to, and indeed some activity on this front with the increased acceptance of ATA disk technology). One could perhaps more reasonably suggest that industry innovation (i.e., competitiveness) has been sluggish in providing lower-cost, at least equally effective alternatives – but that’s a rather different issue.

Management is based on a broken concept? I think not: RAIDs require very minimal managment – just give them another disk once in a while if they need one (or if you need more space), and they’ll take care of the rest, just as virtually as virtual-memory systems handle mapping from one view of memory to a different one.

Don’t confuse support for the LUN abstraction with anything RAID-specific: it’s just a way of continuing support at the RAID level for a pre-existing SCSI single-disk abstraction. Or, if you were referring to using LUNs in a complex multi-RAID array to segregate access and/or allow software striping across multiple internal RAIDs instead of having a single large, somewhat more failure-prone RAID, then (again) this is not a characteristic of RAID itself.

RAID per se simply virtualizes a single-disk abstraction to encompass multiple cooperating disks for increased capacity and/or performance and/or availability. As such, it does so easily and effectively. So perhaps you really meant to suggest that the interface between higher-level software like file systems or databases and the underlying storage (*any* underlying storage – this is hardly specific to RAID) is awkward. If so, don’t blame RAID for supplying what its consumers demand (and demanded long before RAID as such even appeared): blame the consumers for not having adjusted such that they could support something better (because until that happens, anyone developing a better RAID interface won’t have any market at all – which is usually a significant impediment to such innovation from below)..

Parity RAID is architecturally doomed? Rubbish – especially as (again) you confuse more general limitations with something specific to parity RAID.

Disks have indeed increased significantly in size to the point where the likelihood of encountering an unreadable sector during reconstruction is far greater than it once was. But that’s just as true for mirroring as for parity RAID, save for a small constant (1 for a mirror copy vs., say, 4 for a 5-disk RAID-5 array): if we’ve been able to tolerate the 2 to 3 orders of magnitude increase in the probability of encountering such rebuild errors as disk sizes grew over the past couple of decades, a mere factor of 4 seems pretty well down in the noise.

Or, to look at it another way, if the risk of this is excessive for RAID-5, it’s really not all that much less for RAID-1, and *neither* will remain adequate for long. So you’ll be left with the choice between using 3 copies of each datum (for 3x the cost of the underlying storage) or using double-parity RAID (for 1.1x – 1.2x the cost of the underlying storage: double-parity-protected stripes can be quite a bit wider and still retain significant MTTDL advantages): some workloads may be sufficiently performance-critical to justify the expense of the former for all their storage, but most installations will find the latter attractive for at least some of their storage.

There is, of course, also evidence that background disk-scrubbing decreases the probability of encountering bad sectors when you least want to by an order of magnitude of more – but this is applicable to all uses, of course, not just to parity arrays.

Your objection to I/O rates is equally flawed, since IOPS/GB have decreased just as much for single-disk or mirrored configurations as they have for parity RAID. Again, if we’ve been able to tolerate a 2-3 order of magnitude decrease in this value over the past couple of decades, tolerating a mere factor of 2 *only* during degraded read operation seems laughably minor by comparison (especially since in large configurations striped across many small RAID-5 arrays only a small percentage of the data will see *any* such degradation when a disk in one small array fails).

Your suggestion that “those precious IOPS get squandered on read/modify/write cycles” is of course true only for small-write-intensive workloads (full-stripe writes incur no such penalty). Even for small writes, the impact is hardly major (again, compared to the several-orders-of-magnitude decrease in IOPS/GB we’ve tolerated over the last couple of decades): at worst, a small write must first read the preexisting data and parity (two parallel reads, including seek and rotational latency, on separate disks) and then update both (two parallel writes on the same two disks, but without seek latency, though a full rotation is required). One of the reads is often unnecessary, since the original data is still in the disk’s cache. In any event, while using RAID-5 for small-write-intensive workloads may be inadvisable if performance is absolutely critical, there are plenty of workloads where either performance is just *not* that super-critical or small writes just aren’t that frequent, in which case RAID-5 clearly remains a good choice (with the more expensive RAID-1 capacity reserved for workloads that actually *need* it).

One reason why parity RAID may become at least somewhat relatively less attractive in the future is increasing use of off-site replication, where mirroring between sites is usually the only practical approach. Even then, though, if your data is sufficiently important to be mirrored off-site, it may well be sufficiently important that mirroring alone is insufficient protection (or may have sufficiently high availability requirements that the probability of finding the remote copy unavailable after a local disk or sector has failed is unacceptable) – so using local parity RAID as well as remote mirroring may wind up the most cost-effective choice (use RAID-5 at both sites and you can tolerate the failure of any 3 disks without data loss at little more storage cost than just having the two sites mirrored entails, and without the added performance impact of RAID-6). Or you could use 3-way mirroring when performance is more important and you only feel the need to tolerate the loss of any 2 disks.

That pretty much covers my objections, I think. To sum them up, the ‘oncoming train wreck’ that you describe has nothing whatsoever to do with RAID per se, but with the interface between storage (RAIDed or not) and its higher-level clients. ZFS has indeed provided a glimpse of A Better Way to manage this interaction – though I question some of their specific design details (the RAID-Z approach that you describe glowingly elsewhere squanders disk utilization – *every* small write writes an entire stripe, tying up N disks for an I/O apiece, and, worse yet *so does every subsequent read of that data*) and will note that they still use mechanisms similar to RAID-1, RAID-5, and now RAID-6 internally to achieve availability.

By the way, recent Newegg pricing for reputable desktop SATA drives has nearly reached $0.25/GB, with little sign that it’s yet hit rock-bottom. I got my last PATA drive – a 160 GB Seagate – for $0.125/GB, but that was after rebate, whereas Newegg’s prices are out-the-door ones, and last time I checked their prices for ‘near-line’ allegedly more enterprise-quality 7200 rpm SATA drives weren’t a great deal higher.

- bill