On Fri, 21 May 2010, Brandon High wrote:
My understanding is that the controller contains enough cache to buffer enough data to write a complete erase block size, eliminating the need to read / erase / write that a partial block write entails. It's reported to do a copy-on-write, so it doesn't need to do a read of existing blocks when making changes, which gives it such high iops - Even random writes are turned into sequential writes (much like how ZFS works) of entire erase blocks. The excessive spare area is used to ensure that there are always full pages free to write to. (Some vendors are releasing consumer drives with 60/120/240 GB, using 7% reserved space rather than the 27% that the original drives ship with.)
FLASH is useless as working space since it does not behave like RAM so every SSD needs to have some RAM for temporary storage of data. This COW approach seems nice except that it would appear to inflate performance by only considering a specific magic block size and alignment. Other block sizes and alignments would require that existing data be read so that the new block content can be constructed. Also, the blazing fast write speed (which depends on plenty of already erased blocks) would stop once the spare space in the SSD has been consumed.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
