On Sep 27, 2011, at 6:30 PM, Fajar A. Nugraha wrote: > On Wed, Sep 28, 2011 at 8:21 AM, Edward Ned Harvey >> So again: Not a problem if you're making your pool out of SSD's. > > Big problem if your system is already using most of the available IOPSduring > normal operation.
Resilvers are throttled, so they should not impact normal operation. > On Sep 27, 2011, at 6:36 PM, Bob Friesenhahn wrote: > On Tue, 27 Sep 2011, Edward Ned Harvey wrote: >> >> The problem basically applies to HDD's. By creating your pool of SSD's, >> this problem should be eliminated. > > This is not completely true. SSDs will help significantly but they will > still suffer from the synchronized commit of a transaction group. SSDs don't > suffer from seek time, but they still suffer from erase/write time and many > SSDs are capable of only a few thousand flushed writes per second. It is > just a matter of degree. Also, the default settings for the resilver throttle are set for HDDs. For SSDs, it is a good idea to change the throttle to be more aggressive. > SSDs which do garbage collection during the write cycle could cause the whole > vdev to temporarily hang until the last SSD has committed its write. I think this will be unlikely, especially for a resilver workload. Resilvers are done async, so the only time you will be waiting is for the return of the cache flush during txg commit. In the cases I've measured cache flushes, they tend to complete faster on SSDs than HDDs, but it might be worthwhile to characterize this so we know. -- richard -- ZFS and performance consulting http://www.RichardElling.com VMworld Copenhagen, October 17-20 OpenStorage Summit, San Jose, CA, October 24-27 LISA '11, Boston, MA, December 4-9 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
