> For the napkin calculation: On disk, the IEntry is 38Bytes. Alas, > writes occur always in (the ssd internal) blocksize. So, essentially > (assuming 4096 byte blocksize, which is quite optimistic), we have > a write efficiency of less than 1 percent.
While I see how such a model can predict disaster, I don't think that model matches how FTLs work, because it can't. Many file systems (FAT, ext2/3/4) write the same logical block over and over and over and over and over. I think the default interval for ext4 to synch the superblock and the journal is five seconds, which if true is more than 15,000 times every *day* for a busy file system (and I think lots of Linux systems are busy in that sense). > A good firmware in the ssd could avoid needing a new block for the > write, if all bits are changed in teh same direction by the new > data. Again, I believe this model predicts that no regular Linux file system can be used on any SSD, thus I believe this model is not accurate. To quote Wikipedia: https://en.wikipedia.org/wiki/Flash_memory_controller > The mapping units of an FTL can differ so that LBAs are mapped > block-, page- or even sub-page-based. Depending on the usage > pattern, a finer mapping granularity can significantly reduce > the flash wear out and maximize the endurance of a flash based > storage media. Also, I feel as if this point is several assumption layers deep. I think one user reported an unknown number of failures in two sets of SSDs of unknown brand and model. I don't think we know that it was venti SSDs that went bad as opposed to fossil SSDs, let alone knowing it was index SSDs for venti. > It seems, venti in its current form is a ssd killer, if they > are used for the isects. I don't think this claim is yet supported well. Dave Eckhardt ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2ca67486c7a13a77-Mfafe3b0a74f75cd266eb0a73 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
