Comments on: Some nice ZFS related bits http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/ by Mark Mayo Tue, 7 Oct 2008 15:10:02 +0000 http://wordpress.org/?v=2.0.4 by: Dez Blanchfield http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-63082 Mon, 26 Feb 2007 10:56:38 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-63082 The current challenge for those of us working on getting ZFS into mainstream usage is booting a ZFS disk ;-) Mac OS X introducing ZFS can only be seen as great news in my opinion. Cheers, Dez --- Dez Blanchfield http://TheStorageForum.COM The current challenge for those of us working on getting ZFS into mainstream usage is booting a ZFS disk ;-)

Mac OS X introducing ZFS can only be seen as great news in my opinion.

Cheers,

Dez

—
Dez Blanchfield
http://TheStorageForum.COM

]]> by: mark http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49210 Sat, 30 Dec 2006 00:06:04 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49210 Jason: That would be interesting, yes. I'll see if I can't do a raw MB/sec test next week and post the results. Not promising anything, as I don't have much free time, but I'll try. I've seen RAIDZ Thumpers effectively become CPU bottlenecked already, but that was with compression turned on. I'd wager that with compression on, RAIDZ overhead (compared to RAID10) is irrelevant. With compression off, it's hard to believe the RAID xor calc would be of much significance compared to the checksum calcs in ZFS, but ya never know, eh? Jason: That would be interesting, yes. I’ll see if I can’t do a raw MB/sec test next week and post the results. Not promising anything, as I don’t have much free time, but I’ll try.

I’ve seen RAIDZ Thumpers effectively become CPU bottlenecked already, but that was with compression turned on. I’d wager that with compression on, RAIDZ overhead (compared to RAID10) is irrelevant. With compression off, it’s hard to believe the RAID xor calc would be of much significance compared to the checksum calcs in ZFS, but ya never know, eh?

]]> by: Jason J. W. Williams http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49208 Fri, 29 Dec 2006 23:53:38 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49208 I'm curious how RAID-Z and RAID-Z2 hold up performance-wise on the thumper to a Thumper RAID-10 instead. I’m curious how RAID-Z and RAID-Z2 hold up performance-wise on the thumper to a Thumper RAID-10 instead.

]]> by: mark http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49172 Fri, 29 Dec 2006 19:22:44 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49172 rdoetjes: RAID 1+0 is a nice luxury but it's not necessarily the ideal setup. For example, for about the same number of disks, one could do an independant pair of RAID6 arrays attached to different hosts and replicate the data between them. That's better availability than pure RAID10 for not a lot more cash. And there are times when it simply doesn't make sense to spend the extra money when statistically, a good RAID6 implementation can actually offer (arguably) better protection against double disk failures. The logic being that in RAID6, any two disks can fail, whereas with RAID10 it's *possible* you could loose the two disks making up one of the RAID1 pairs. I'd also argue that for the most part, the overhead of the RAID calcs isn't a real problem these days. CPUs and/or controllers are fast and cheap. There are exceptions, of course, and I too still deploy RAID10 arrays fairly regularly (primarily on low-spindle count arrays), but saying "stand clear of any raid 6,5,4,3 like system" is poor advice. There are very few general assumptions one can safely make in the world of multi-disk data storage, and this certainly isn't one of them. Know your application, know your storage hardware, know your risks tolerances, and then decide what setup best fits the situation. rdoetjes: RAID 1+0 is a nice luxury but it’s not necessarily the ideal setup. For example, for about the same number of disks, one could do an independant pair of RAID6 arrays attached to different hosts and replicate the data between them. That’s better availability than pure RAID10 for not a lot more cash. And there are times when it simply doesn’t make sense to spend the extra money when statistically, a good RAID6 implementation can actually offer (arguably) better protection against double disk failures. The logic being that in RAID6, any two disks can fail, whereas with RAID10 it’s *possible* you could loose the two disks making up one of the RAID1 pairs. I’d also argue that for the most part, the overhead of the RAID calcs isn’t a real problem these days. CPUs and/or controllers are fast and cheap.

There are exceptions, of course, and I too still deploy RAID10 arrays fairly regularly (primarily on low-spindle count arrays), but saying “stand clear of any raid 6,5,4,3 like system” is poor advice. There are very few general assumptions one can safely make in the world of multi-disk data storage, and this certainly isn’t one of them. Know your application, know your storage hardware, know your risks tolerances, and then decide what setup best fits the situation.

]]> by: rdoetjes http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49159 Fri, 29 Dec 2006 16:56:36 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-49159 I would suggest to stand clear of any raid 6,5,4,3 like systems. The generate such an overhead that will at least in my field (databases and HPC) create bottlenecks. I can't remember the last time I've setup a RAID5 like system. I would suggest to stand clear of any raid 6,5,4,3 like systems. The generate such an overhead that will at least in my field (databases and HPC) create bottlenecks.
I can’t remember the last time I’ve setup a RAID5 like system.

]]> by: mark http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-48851 Wed, 27 Dec 2006 18:33:15 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-48851 JoeV: Yes, exactly. JoeV: Yes, exactly.

]]> by: JoeV http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-48800 Wed, 27 Dec 2006 13:29:04 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-48800 RAIDZ2 can handle double disk failures. RAIDZ2 can handle double disk failures.

]]> by: mark http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-47674 Thu, 21 Dec 2006 19:31:08 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-47674 I consider RAIDZ unusable (note that I qualified it with "on the systems I use") because it doesn't handle double disk failures. With today's drives reaching 750GB, array rebuilds can take a long, long time. I don't want to be exposed to a second disk failure during that window, especially since, in my experiennce, it's not unusual for the heavy I/O of a rebuild operation to "trigger" a second disk failure. I consider RAIDZ unusable (note that I qualified it with “on the systems I use”) because it doesn’t handle double disk failures. With today’s drives reaching 750GB, array rebuilds can take a long, long time. I don’t want to be exposed to a second disk failure during that window, especially since, in my experiennce, it’s not unusual for the heavy I/O of a rebuild operation to “trigger” a second disk failure.

]]> by: bbr http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-47596 Thu, 21 Dec 2006 10:36:51 +0000 http://www.vmunix.com/mark/blog/archives/2006/12/18/some-nice-zfs-related-bits/#comment-47596 why did you consider RAIDZ unusable? why did you consider RAIDZ unusable?

]]>