Once upon a time, hard disk transfer rates were an issue of seriousconcern. It mattered a great deal how fast your disks and their IOchannels could run, and changing technologies could have significantperformance effects; IDE versus SCSI and so on really made a difference.

For a lot of people, those days are long over. Disk interconnects areessentially irrelevant (for this) and streaming read and write bandwidthhas become if not irrelevant then generally not important. What matters,what limits performance, is seek time.

Given the previous entry , here's my opinions so faron when you should let ZFS handle your redundancy and when you shouldhave your storage backend do RAID. (This assumes that you have a storagebackend; if not, well, you don't have much choice.)

• if you are doing mirroring, you really want to let ZFS handleit because ZFS will do a much better job of handling small problemsthan your storage backend can.

• if you have a SAN and need your frontends to survive temporary

In a comment on my last entry , Matt Simmons asked why you'd let ZFS handleRAID level issues instead of just handling them in your storage backend(SAN or otherwise). Having ZFS do this is the recommended practice, fora number of reasons (some of which the ZFS FAQs will tell you about).

Here's the reasons for letting ZFS handle the RAID stuff that I knowabout (or at least can think of right now):

• ZFS can reliably repair corrupted blocks in mirrors , because