On Sat, Oct 24, 2009 at 03:31:25PM -0400, Jim Mauro wrote: > Posting to zfs-discuss. There's no reason this needs to be > kept confidential. > > 5-disk RAIDZ2 - doesn't that equate to only 3 data disks? > Seems pointless - they'd be much better off using mirrors, > which is a better choice for random IO...
Is it really pointless? Maybe they want the insurance RAIDZ2 provides. Given the choice between insurance and performance, I'll take insurance, though it depends on your use case. We're using 5-disk RAIDZ2 vdevs. While I want the performance a mirrored vdev would give, it scares me that you're just one drive away from a failed pool. Of course, you could have two mirrors in each vdev but I don't want to sacrifice that much space. However, over the last two years, we haven't had any demonstratable failures that would give us cause for concern. But, it's still unsettling. Would love to hear other opinions on this. > Looking at this now... > > /jim > > > Jeff Savit wrote: >> Hi all, >> >> I'm looking for suggestions for the following situation: I'm helping >> another SE with a customer using Thumper with a large ZFS pool mostly >> used as an NFS server, and disappointments in performance. The storage >> is an intermediate holding place for data to be fed into a relational >> database, and the statement is that the NFS side can't keep up with >> data feeds written to it as flat files. >> >> The ZFS pool has 8 5-volume RAIDZ2 groups, for 7.3TB of storage, with >> 1.74TB available. Plenty of idle CPU as shown by vmstat and mpstat. >> iostat shows queued I/O and I'm not happy about the total latencies - >> wsvc_t in excess of 75ms at times. Average of ~60KB per read and only >> ~2.5KB per write. Evil Tuning guide tells me that RAIDZ2 is happiest >> for long reads and writes, and this is not the use case here. >> >> I was surprised to see commands like tar, rm, and chown running >> locally on the NFS server, so it looks like they're locally doing file >> maintenance and pruning at the same time it's being accessed remotely. >> That makes sense to me for the short write lengths and for the high >> ZFS ACL activity shown by DTrace. I wonder if there is a lot of sync >> I/O that would benefit from separately defined ZILs (whether SSD or >> not), so I've asked them to look for fsync activity. >> >> Data collected thus far is listed below. I've asked for verification >> of the Solaris 10 level (I believe it's S10u6) and ZFS recordsize. >> Any suggestions will be appreciated. >> >> regards, Jeff -- albert chin (ch...@thewrittenword.com) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
