$article_text =~ s/RIAD/RAID/g;

Also, you did not explain how parity works, which is something that confuses RAID newcomers. They need to fathom the concept that the parity is combined with the surrounding data to compute what the original data was so that it can be recreated.

but in general, I think people are gradually realizing that block-level raid is eventually going to become obsolete. there are a lot of advantages to letting a smart filesystem manage redundancy, since that permits file/access-aware choices, and can mitigate some of the issues of block-level raid rebuilds.

And not a peep about how any of these relate to linux in an article in something calling itself linuxmag?

Not even a mention of mdraid?

@roustabout: RAID-3 and RAID-4 were part of the original RAID definition. I didn’t see what I called them “two of the most common RAID levels”. If I did, the intent is to point out that they are part of the original RAID definitions, but commonly _used_.

For everyone who is concerned that I haven’t talked about mdadm or software RAID, hardware RAID, or “fakeRAID” – that article is coming (as are articles about Nested RAID). This is a whole series of introductory articles on RAID. Talking about specific implementations, particularly for Linux, is coming. You just have to be patient. So @roustabout – you will just have to be patient :)

@markhahn – great comment and I totally agree with you but I also disagree to some extent. Putting RAID functionality into the file system _should_ allow the file system to do really useful things such as only recover the needed blocks during a disk failure. This avoids having to read all of the blocks for recovery and perhaps coming close to the dreaded URE limit.

But this means that we (the community) needs to rewrite all file systems to do this. With each file system being unique this means we are going to have different sets of code that do pretty much the same thing. I don’t think existing file systems will do this (too much work and too disruptive) so that means future file systems should incorporate this (such as btrfs). However, it takes a very long time for a file system to mature so we may be waiting for several years. So in the meantime, I think block-based RAID is here to stay.

On the other hand, I think the development of object based file systems that don’t use block-based RAID, should be the wave of the future. PanFS from Panasas is an example of this. I think local file systems should adopt this approach (and we’re seeing some of this with ExoFS) because we don’t need to read all the blocks to recover from a disk failure – just the objects that are “missing” or need to be duplicated.

Thanks for bringing up the topic – always good to think about what we need to do next few years.

Jeff