[GLLUG] RAID1 and Debian 7.2.0 installer

[Mike Brodbelt]

On 14/10/13 19:22, Martin A. Brooks wrote:

> No.  RAID6, and for that matter, 0, 1, 2, 3, 4, 5 and combinations
> thereof, don't protect at all against an rm in the wrong place.

Snapshots protect just fine against user error.

> RAID levels that involve parity are highly questionable in any case.
> We're not in the 20th century anymore.

Parity is going to be around for some time to come, and there seems to 
be no particularly sensible reason to regard it as "unsafe at any speed".

Adam Leventhal did considerable research on this at Sun, resulting in 
the integration of triple parity subvolumes into ZFS, and a fairly 
comprehensive ACM article that's available at 
http://queue.acm.org/detail.cfm?id=1670144, and has real numbers. My 
personal view of that RAID-5 is unacceptable for anything important, 
RAID-6 is tolerable today, and I'd like triple parity by the time member 
disks cross the 5Tb mark YMMV.

Given the technology roadmap visible now, it seems that the immediate 
future of bulk data storage is still likely to feature plenty of parity 
based systems on spinning disks. Large systems require maintenance - 
regular disk scrubs, block level checksumming, and various other safety 
metrics will all play a part.

It saddens me that Linux never managed to get ZFS in a meaningful way - 
it's been a production grade filesystem for well over 5 years now, that 
solved many of these problems well, and early (copy-on-write snapshots, 
blcok checksums, dedupe, compression, schedulable resilver, integrated 
volume management, and more). BtrFS still isn't there, and won't have 
the track record for several more years, even assuming it makes it out 
the door soon. If you're building a storage system today, using 
Debian/kFreeBSD, or one of the other routes that gets you a ZFS capable 
kernel (including http://zfsonlinux.org/) looks pretty attractive in 
many ways. However, as a 128bit filesystem you need a 64 bit machine 
with lots of memory to make it work well, and the nature of the fs means 
that performance degrades sharply as it gets full - basically never fill 
a ZFS filesystem over 80%.

Mike