Hi All ; Every NAND based SSD HDD have some ram. Consumer grade products will have smaller not battery protected ram with a smaller number of prallel working nand chips and a slower cpu to distribute the load. Also consumer product will have less number of spare cells.
Enterprise SSD's are genrally compose of several nand devices and a lot of spare cells controlled by a fast micro computer which also have some cache and a super capacitor to protect the cache. Regardless of NAND write cycle capability, vendors can design a reliable SSD with incorprating more spare cells in to the desing. Mertol Mertol Ozyoney Storage Practice - Sales Manager Sun Microsystems, TR Istanbul TR Phone +902123352200 Mobile +905339310752 Fax +902123352222 Email [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard L. Hamilton Sent: Wednesday, June 11, 2008 2:58 PM To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] SSD reliability, wear levelling, warranty period > > btw: it's seems to me that this thread is a little > bit OT. > > I don't think its OT - because SSDs make perfect > sense as ZFS log > and/or cache devices. If I did not make that clear > in my OP then I > failed to communicate clearly. In both these roles > (log/cache) > reliability is of the utmost importance. Older SSDs (before cheap and relatively high-cycle-limit flash) were RAM cache+battery+hard disk. Surely RAM+battery+flash is also possible; the battery only needs to keep the RAM alive long enough to stage to the flash. That keeps the write count on the flash down, and the speed up (RAM being faster than flash). Such a device would of course cost more, and be less dense (given having to have battery+charging circuits and RAM as well as flash), than a pure flash device. But with more limited write rates needed, and no moving parts, _provided_ it has full ECC and maybe radiation-hardened flash (if that exists), I can't imagine why such a device couldn't be exceedingly reliable and have quite a long lifetime (with the battery, hopefully replaceable, being more of a limitation than the flash). It could be a matter of paying for how much quality you want... As for reliability, from zpool(1m): >log > > A separate intent log device. If more than one log device is specified, > then > writes are load-balanced between devices. Log devices can be mirrored. > However, raidz and raidz2 are not supported for the intent log. For more > information, see the “Intent Log” section. > > cache > > A device used to cache storage pool data. A cache device cannot be mirrored > or part of a raidz or raidz2 configuration. For more information, see the > “Cache Devices” section. [...] > Cache Devices > > Devices can be added to a storage pool as “cache devices.” These devices > provide an additional layer of caching between main memory and disk. For > read-heavy workloads, where the working set size is much larger than what can > be cached in main memory, using cache devices allow much more of this > working set to be served from low latency media. Using cache devices provides > the greatest performance improvement for random read-workloads of mostly > static content. > > To create a pool with cache devices, specify a “cache” vdev with any number > of devices. For example: > > # zpool create pool c0d0 c1d0 cache c2d0 c3d0 > > Cache devices cannot be mirrored or part of a raidz configuration. If a > read > error is encountered on a cache device, that read I/O is reissued to the > original storage pool device, which might be part of a mirrored or raidz > configuration. > > The content of the cache devices is considered volatile, as is the case with > other system caches. That tells me that the zil can be mirrored and zfs can recover from cache errors. I think that means that these devices don't need to be any more reliable than regular disks, just much faster. So...expensive ultra-reliability SSD, or much less expensive SSD plus mirrored zil? Given what zfs can do with cheap SATA, my bet is on the latter... This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
