5 ms·
This is a useful datapoint, but I feel the author could learn a thing or two from the backblaze disk report. It looks like there are a few use cases that cause
by S_A_P 8y ago
This is a useful datapoint, but I feel the author could learn a thing or two from the backblaze disk report. It looks like there are a few use cases that cause high wear on SSDs. I dont see a lot of concrete numbers here. To me, it is more useful to say something like: these ssds will last 2 years given that their sustained write throughput is X GB/sec on average.
From the SSD torture tests Ive seen, it is many petabytes of data that the average SSD must write before getting anywhere near "weared out".
- mtmail 8y agohttps://www.heise.de/newsticker/meldung/SSD-Langzeittest-beendet-Exitus-bei-9-1-Petabyte-3755009.html https://www.heise.de/newsticker/meldung/SSD-Langzeittest-bee... (German) did a long-term test of 12 drives in 2016. The best drive (Samsung SSD 850) managed 9.1PB, that took a year of constant writing, the worst (Crucials BX200) about 200TB. All drives managed multiple times more than specified.
- AstralStorm 8y agoThat is before quite amplification which can be pretty high. Real value depends on block size and write algorithms employed.
- milesvp 8y agoMy understanding with flash, having talked to someone who had to write his own wear-leveling code so his hardware could use cheap memory, is it's not so much the pure throughout that can kill a flash cell, but the write pattern that matters. My memory of the conversation is a bit hazy, but it's something like, in order to update even a single bit in a cell, it needs to be deleted and written to, and each cell only has so many write statistically before it's flagged no good. So to detroy a disk, you can strategically flip bits all over your disk, or with a disk with naive wear-leveling maybe just flip the same bit over and over. Good disks will make this harder with tricks like buffers (hopefully backed by batt/cap in the event of power outtage), and very clever wear-leveling algos, but you can definitely wear out flash memory with a fraction of the data and time you might expect if you have a truly pathological workload.
- astrodust 8y agoFlash memory is different from a regular drive, and it's to do with how it writes. You can't alter a single bit, you must rewrite the whole block and those can be anywhere from 256KB to 4MB or more. http://codecapsule.com/2014/02/12/coding-for-ssds-part-2-architecture-of-an-ssd-and-benchmarking/ http://codecapsule.com/2014/02/12/coding-for-ssds-part-2-arc... Adding new bits is cheap, though, so if you can come up with an append-only strategy for your system and periodically combine those into a new, pristine version you'll get far more life out of your SSD than if you go around randomly flipping bits. Is Redis using memory-mapped files the problem here? Treating a file like memory is all fine and good until your random bit-flipping has to be directly persisted. I wonder if future SSD firmware implementations will avoid wear by having a small buffer reserved for little post-write patches that can absorb a few small changes before having to commit to rebuilding the whole block. There's talk of "annealing" as a way of restoring cells to full life: https://www.extremetech.com/computing/142096-self-healing-self-heating-flash-memory-survives-more-than-100-million-cycles https://www.extremetech.com/computing/142096-self-healing-se... Has anyone tried reflowing a worn out drive?
- planteen 8y agoFlash must be erased on a page boundary, the size of which varies, but ranges from 512 bytes up. The act of erasing a flash page turns all bits to 1s (0xFF for the entire page). When the flash IC breaks, you can usually tell by doing a blank check after erasing. Instead of being 0xFF all over, some bits will be "stuck" to 0. A common reason for a discrete IC flash part wearing out is that charge pumps are used to raise a low voltage like 3.3 V to 12-15 V which is required for erasing. These charge pumps are touchy and can die first, from what I have heard.
- nomel 8y agoSome care has to be taken when saying a "petabyte of data" with flash media. You don't have to write a petabyte of data to reach a petabyte of SSD writes. The minimum block size that flash can write is an "erase block", which is usually a few megabytes. This means that the minimum SSD write will be at least a few megabytes, including that few hundred bytes to that logfile. Likewise, every flushed write will round up to the nearest erase block, in size. So, to write a few petabytes to the drive, you only need a few gigabytes of writes of per-byte-flushed data, since your actual NAND writes are amplified by a few million. There's cache and many smart algorithms at play to minimize the number of erase block writes, but once you cause a flush (close the file, etc), you're performing a write to flash. This is also why any embedded system with logging enabled has a very real maximum operating life. This is fun to discover the first time, when all of your customers start saying your product stopped working within the same couple of months.
- sp332 8y agoThe most common size I'm seeing for erase blocks is 128kB. The only drives I found with erase blocks over 1 MB are the Samsung TLC drives like the 840.
- wtallis 8y agoYou must be looking at really old info, which is understandable because page and erase block sizes for current NAND is often hard to get. The first generation of Intel/Micron 3D NAND used 16kB pages and 16MB/24MB erase blocks for MLC and TLC.
- xenofanes 8y agoSome clarifications: Minimum SSD write is much less than the erase block. Erase block is the minimum block size that can be erased. For SSDS, there are 2 key concepts: 1. Read granularity < write granularity < erase granularity 2. Cells that have been written to must be erased before writing again. Most SSD vendors will buffer write contents to collect a `write granularity` worth of data to avoid wasting bytes writing padding. This can be hard to do on drives without capacitors to supply backup power in the event of power loss.
- userbinator 8y agoFrom the SSD torture tests Ive seen, it is many petabytes of data that the average SSD must write before getting anywhere near "weared out". What those tests don't show by continuously writing and reading until absolute failure is the degradation in retention that occurs; a block that has been erased and rewritten over the specified endurance will almost certainly still accept writes, and even read back the same data, but is unlikely to retain that data for the specified length of time (several years, normally) --- instead, erasing itself soon after being written.
- mdekkers 8y agobefore getting anywhere near "weared out". Well done you, picking on a non-native English speaker! Very welcoming and inclusive.
- dang 8y agoI agree with you that people need to respect non-native speakers. But attacking someone doesn't promote respect. Please don't attack others on HN. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- chupasaurus 8y ago> these ssds will last 2 years given that their sustained write throughput is X GB/sec on average You are forgetting that Okmeter is a monitoring tool, not a backup warehouse. They are talking about the causes the fast wearout was made and how you could detect it with their product. Backblaze on the other hand is all about data storage and they have a good statistics because of massive amount of discs they use, so they are making reports about specific models and how they behave.