The issue as presented by Tonmaus was that a scrub was negatively impacting his RAIDZ2 CIFS performance, but he didn't see the same impact with RAIDZ. I'm not going to say whether that is a "problem" one way or the other; it may be expected behavior under the circumstances. That's for ZFS developers to speak on. (This was one of many issues Tonmaus mentioned.)
However, what was lost was the context. Tonmaus reported this behavior on a commodity server using slow disks in an 11 disk RAIDZ2 set. However, he *really* wants to know if this will be an issue on a 100+ TB pool. So his examples were given on a pool that was possibly 5% of the size the pool that he actually wants to deploy. He never said any of this in the original e-mail, so Richard assumed the context to be the smaller system. That's why I pointed out all of the discrepancies and questions he could/should have asked which might have yielded more useful answers. There's quite a difference between the 11 disk RAIDZ2 set and a 100+ TB ZFS pool, especially when the use case, VDEV layout and other design aspects of the 100+ TB pool have not been described. On Tue, Mar 16, 2010 at 13:41, David Dyer-Bennet <d...@dd-b.net> wrote: > > On Tue, March 16, 2010 11:53, thomas wrote: > > Even if it might not be the best technical solution, I think what a lot > of > > people are looking for when this comes up is a knob they can use to say > "I > > only want X IOPS per vdev" (in addition to low prioritization) to be used > > while scrubbing. Doing so probably helps them feel more at ease that they > > have some excess capacity on cpu and vdev if production traffic should > > come along. > > > > That's probably a false sense of moderating resource usage when the > > current "full speed, but lowest prioritization" is just as good and would > > finish quicker.. but, it gives them peace of mind? > > I may have been reading too quickly, but I have the impression that at > least some of the people not happy with the current prioritization were > reporting severe impacts to non-scrub performance when a scrub was in > progress. If that's the case, then they have a real problem, they're not > just looking for more peace of mind in a hypothetical situation. > -- > David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ > Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ > Photos: http://dd-b.net/photography/gallery/ > Dragaera: http://dragaera.info > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > -- "You can choose your friends, you can choose the deals." - Equity Private "If Linux is faster, it's a Solaris bug." - Phil Harman Blog - http://whatderass.blogspot.com/ Twitter - @khyron4eva
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
