Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every programmer should know about SSDs

databasearchitects.blogspot.com

Post reply on HN
Print view View original

71–80 of 163 posts

Re: What every programmer should know about SSDs

#71

Post by wtallis »

mercora wrote: post #30
teddyh wrote: post #19

What everyone should know is that flash drives can lose their data when left unpowered for as little as three months.

if that is true disks should come with a very visible note stating this... seriously, 3 months would be nothing. i doubt it is true because 3 months is a time frame which should be surpassed quite often making this more known.

Three months is the minimum standard for data retention from an enterprise SSD that has used up its entire write endurance and reached end of life, but is still being stored in a hot chassis.

Outside of that narrow scenario, the three months figure is wildly wrong and should not be repeated. Lower temperatures, a consumer drive, and not having used up 100% of the write endurance will all drastically lengthen data retention.

(However, under no circumstances should you trust a cheap USB thumb drive to retain your data. Those tend to use lower-grade flash memory and lower-quality controllers. If you need an external device to reliably cart around data, shop for a "portable SSD", not a "USB flash drive".)

Re: What every programmer should know about SSDs

#72

Post by wtallis »

cbsmith wrote: post #41
wtallis wrote: post #15

Earlier quoted context omitted.

SSDs mostly tell the host system that they have 512-byte sectors or sometimes 4kB sectors, and the typical flash translation layer works in 4kB sectors because that's a good fit for the kind of workloads coming from a host system that usually prefers to do things (eg. virtual memory) in 4kB chunks. But the underlying NAND flash page size has been 16kB for years.

...and all that cruft, and the logic to try to make handling of it not so bad, makes for a lot of complexity and unintended consequences.

Emulating 4kB or 512B sectors when the underlying media has a 16kB native page size really doesn't add much more complexity on top of the stuff that was already required to handle the fact that erase blocks are multiple megabytes.

Re: What every programmer should know about SSDs

#74

Post by abledon »

kortilla wrote: post #18

The title should be “why SSDs mean programmers no longer have to think about hard drives”. These are all reasons SSDs are much more pleasant to work with than old platter disks.

Why every programmer of a small subset of programmers who actually need to know this

Re: What every programmer should know about SSDs

#75

Post by ifdefdebug »

jedberg wrote: post #16

This page tells me a lot about SSDs, but it doesn't tell me why I need to know these things. It doesn't really give me any indication about how I should change my behavior if I know that I'll be running on SSD vs spinning disk. I've always been told, "just treat SSDs like slow, permanent memory".

For instance, when reading this sqlite came immediately to my mind and how much a 10000 loop of inserts without begin/commit or some preparing pragmas would wreck a ssd... (forces a full sync between each two inserts)

Re: What every programmer should know about SSDs

#77

Post by gravypod »

bob1029 wrote: post #26

Things I have learned about SSDs: If you want to go fast & save NAND lifetime, use append-only log structures. If you want to go even faster & save even more NAND lifetime, batch your writes in software (i.e. some ring buffer with natural back-pressure mechanism) and then serialize them with a single writer into an append-only log structure. Many newer devices have something like this at the hardware level, but your…

This is the "secret sauce" behind LevelDB: https://github.com/google/leveldb#performance

Re: What every programmer should know about SSDs

#78

Post by gruez »

crazygringo wrote: post #61
teddyh wrote: post #19

What everyone should know is that flash drives can lose their data when left unpowered for as little as three months.

Do you have a current source for that? I've turned on plenty of cell phones that hadn't been charged or powered on for a couple of years and everything worked normally. Same with thumb drives I've picked up after years. I mean, anything can fail after three months. Your statement doesn't really add anything without stating the failure rates . For all I know the failure rate could be less than that of physical hard dr…

https://images.anandtech.com/doci/9248/2_575px.PNG

from https://www.anandtech.com/show/9248/the-truth-about-ssd-data...

Re: What every programmer should know about SSDs

#79

Post by jedberg »

ifdefdebug wrote: post #75
jedberg wrote: post #16

This page tells me a lot about SSDs, but it doesn't tell me why I need to know these things. It doesn't really give me any indication about how I should change my behavior if I know that I'll be running on SSD vs spinning disk. I've always been told, "just treat SSDs like slow, permanent memory".

For instance, when reading this sqlite came immediately to my mind and how much a 10000 loop of inserts without begin/commit or some preparing pragmas would wreck a ssd... (forces a full sync between each two inserts)

Not really though, because your kernel would most likely abstract that away and bunch up the writes.

Re: What every programmer should know about SSDs

#80

Post by gruez »

ifdefdebug wrote: post #75
jedberg wrote: post #16

This page tells me a lot about SSDs, but it doesn't tell me why I need to know these things. It doesn't really give me any indication about how I should change my behavior if I know that I'll be running on SSD vs spinning disk. I've always been told, "just treat SSDs like slow, permanent memory".

For instance, when reading this sqlite came immediately to my mind and how much a 10000 loop of inserts without begin/commit or some preparing pragmas would wreck a ssd... (forces a full sync between each two inserts)

Fortunately most people aren't running OLTP workloads on client SSDs. That's mostly done on enterprise SSDs that have much higher endurance. That said even on client SSDs you can probably get away with running such workloads as long as you're not doing them 24/7.
Post reply on HN