Comments below. On 29 January 2011 00:25, Edward Ned Harvey < opensolarisisdeadlongliveopensola...@nedharvey.com> wrote:
> This was something interesting I found recently. Apparently for flash > manufacturers, flash hard drives are like the pimple on the butt of the > elephant. A vast majority of the flash production in the world goes into > devices like smartphones, cameras, tablets, etc. Only a slim minority goes > into hard drives. http://www.eetimes.com/electronics-news/4206361/SSDs--Still-not-a--solid-state--business ~6.1 percent for 2010, from that estimate (first thing that Google turned up). Not denying what you said, I just like real figures rather than random hearsay. > As a result, they optimize for these other devices, and > one of the important side effects is that standard flash chips use an 8K > page size. But hard drives use either 4K or 512B. > http://www.anandtech.com/Show/Index/2738?cPage=19&all=False&sort=0&page=5 Terms: "page" means the smallest data size that can be read or programmed (written). "Block" means the smallest data size that can be erased. SSDs commonly have a page size of 4KiB and a block size of 512KiB. I'd take Anandtech's word on it. There is probably some variance across the market, but for the vast majority, this is true. Wikipedia's http://en.wikipedia.org/wiki/Flash_memory#NAND_memories says that common page sizes are 512B, 2KiB, and 4KiB. The SSD controller secretly remaps blocks internally, and aggregates small > writes into a single 8K write, so there's really no way for the OS to know > if it's writing to a 4K block which happens to be shared with another 4K > block in the 8K page. So it's unavoidable, and whenever it happens, the > drive can't simply write. It must read modify write, which is obviously > much slower. > This is be true, but for 512B to 4KiB aggregation, as the 8KiB page doesn't exist. As for writing when everything is full, and you need to do an erase..... well this is where TRIM is helpful. Also if you look up the specs of a SSD, both for IOPS and/or sustainable > throughput... They lie. Well, technically they're not lying because > technically it is *possible* to reach whatever they say. Optimize your > usage patterns and only use blank drives which are new from box, or have > been fully TRIM'd. Pfffft... But in my experience, reality is about 50% > of > whatever they say. > > Presently, the only way to deal with all this is via the TRIM command, > which > cannot eliminate the read/modify/write, but can reduce their occurrence. > Make sure your OS supports TRIM. I'm not sure at what point ZFS added > TRIM, > or to what extent... Can't really measure the effectiveness myself. > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6957655 <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6957655> > Long story short, in the real world, you can expect the DDRDrive to crush > and shame the performance of any SSD you can find. It's mostly a question > of PCIe slot versus SAS/SATA slot, and other characteristics you might care > about, like external power, etc. Sure, DDR RAM will have a much quicker sync write time. This isn't really a surprising result.
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
