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

Everything I Know About SSDs

kcall.co.uk

Post reply on HN
Print view View original

121–130 of 190 posts

Re: Everything I Know About SSDs

#121

Post by wtallis »

toast0 wrote: post #69
computator wrote: post #41

> Deleted file recovery on a modern SSD is next to impossible for the end user OK, he’s talking about SSDs, but I want to mention that I’ve easily recovered many large deleted files from SD or micro-SD cards (formatted as FAT32 or exFAT) using Norton Unerase or an equivalent utility. Are the controllers for SSDs that different from the controllers for SD cards? Has anyone tried Norton Unerase or an equivalent program…

It would likely depend of if the filesystem uses TRIM to notify the SSD of deleted sectors. If it doesn't, the deleted files should retain their data until the filesystem reuses the sector, as normal. If trim is used, the SSD doesn't have to retain the data, but it doesn't necessarily make it unreadable immediately, there are many implementation strategies for trim.

Enterprise SSDs for the most part promise that reading a trimmed range of the drive will return zeros. Consumer SSDs usually won't make that strong of a guarantee, so that if you're running enterprise software that requires this behavior you have to pay extra for enterprise drives. As originally formulated, the TRIM command was supposed to be more of a hint that the SSD could ignore if it was too busy or if the TRIMMed block was too small for the drive to do anything useful with.

Re: Everything I Know About SSDs

#122

Post by labawi »

m4rtink wrote: post #48
24gttghh wrote: post #14

Earlier quoted context omitted.

A very basic nuclear reactor can be explained pretty simply I think. You enrich a bunch of let's say uranium. Pack it together in a rod, and put a bunch of those rods in a pond. Those rods have controlled (ideally) nuclear decay from their being in close proximity to other rods which generates a lot of heat, which is transferred to a separate cooling loop that boils water to make steam which drives an electric turbin…

What you describe is basically a radioisotope thermal generator, like those used by space probes. In such a device, you use natural decay heat of unstable radioisotopes. In a nucler reactor, things are a bit different. You start with uranium that is only slightly rsdioactive and does not produce any usable quantities of heat. You place in ib the corrrct geometry and start a controlled nuclear chain reaction. You jave…

I think the harder part is making the reactor safe, idiot proof, bomb material production semi-incapable, issues of dealing with remaining irradiated materials..

Also politics, corruption etc.

Re: Everything I Know About SSDs

#123

Post by jlokier »

wtallis wrote: post #105
jlokier wrote: post #104

Earlier quoted context omitted.

Native command queuing won't help with placement decisions . (And the NCQ queue is rather short anyway for scheduling optimisation.) For example, even something as trivial and linear as a database log or filesystem log can benefit from placement optimisation. Each time there's a transaction to commit, instead of writing the next commit record to the next LBA number in the log, increment the LBA number by an amount th…

> (And the NCQ queue is rather short anyway for scheduling optimisation.) Isn't it 31 or 32 commands in the queue? That's a worst-case of around a quarter second for a 7200rpm drive, which sounds like an awfully long time horizon to me.

That's probably why the queue depth is limited in NCQ. It's not intended to do bulk parallel scheduling, and as you imply, you wouldn't want the drive committed to anything for much longer than that.

But for ideal scheduling, you need something to deal with the short timings as well.

For example, if you have 1024 x 512-byte single-sector randomly arriving reads, of which 512 sectors happen to be in contiguous zone A and 512 sectors happen to be in contiguous zone B, all of those reads together will take about 2 seek times and 2 rotation times.

Assuming the generators of those requests are some intensively parallel workload (so there can be perfect scheduling), which is heavily clustered in the two zones (e.g. two database-like files), my back-of-the-envelope math comes to Generally that's what the kernel I/O scheduler is for.

Re: Everything I Know About SSDs

#124

Post by rasz »

mjw1007 wrote: post #59

I hoped it would discuss how SSDs cope with sudden power loss, but it doesn't seem to. I remember this page but I don't know of a modern update: http://lkcl.net/reports/ssd_analysis.html These days, if I want an SSD for my desktop and want to minimise the chance I have a disk problem and have to restore from backup, would I be better off with one "data centre" drive (eg Intel D3-S4510), or two mirrored "consumer" dri…

Intel SSDs are known for advertising graceful degradation to Read Only mode, when in reality simply suddenly die during endurance tests.

Re: Everything I Know About SSDs

#125

Post by rasz »

wtallis wrote: post #114
ls612 wrote: post #107

Earlier quoted context omitted.

I have an NVME SSD as a boot drive in my desktop and three years and change in (say 1200 days) it’s used 40tb of write (out of an advertised 400tb endurance so I’m not too worried). That works out to about 30gb of writes per day, which seems about right for medium to heavy use. I guess what I’m saying is that for modern SSDs I don’t think write endurance is a binding constraint in most cases.

For client/consumer SSDs, most vendors seem to view 50GB/day as plenty of write endurance for mainstream, non-enthusiast products. Virtually all retail consumer SSDs have a warranty that covers at least that much, and usually several times more for larger drive capacities (since write endurance is more often specified in drive writes per day).

Coincidentally 50GB/day is what Chrome craps out to the hard drive during few hours of usage, doing such clever things like "caching" YT videos (YT player NEVER reuses data, and rewinding always generates new server fetch with new randomly generated URL).

Re: Everything I Know About SSDs

#126

Post by wtallis »

rasz wrote: post #124
mjw1007 wrote: post #59

I hoped it would discuss how SSDs cope with sudden power loss, but it doesn't seem to. I remember this page but I don't know of a modern update: http://lkcl.net/reports/ssd_analysis.html These days, if I want an SSD for my desktop and want to minimise the chance I have a disk problem and have to restore from backup, would I be better off with one "data centre" drive (eg Intel D3-S4510), or two mirrored "consumer" dri…

Intel SSDs are known for advertising graceful degradation to Read Only mode, when in reality simply suddenly die during endurance tests.

As I recall, there are at least three problems here:

1. Basically no software is prepared to be "graceful" about their storage suddenly going read-only, especially when the OS is trying to run off that drive.

2. Intel drives at end of life go read-only until the next power cycle, whereupon they turn into bricks.

3. The threshold at which Intel drives go read-only is when the warrantied write endurance runs out, not when the actual error rate becomes problematic. This makes sense if the drive is trying to ensure the flash is still in good enough condition to have long data retention, so that you can reliably and easily recover data from the drive. But (2) already rules that out.

Re: Everything I Know About SSDs

#127

Post by geocrasher »

cattlemansgold wrote: post #43
24gttghh wrote: post #14

Earlier quoted context omitted.

A very basic nuclear reactor can be explained pretty simply I think. You enrich a bunch of let's say uranium. Pack it together in a rod, and put a bunch of those rods in a pond. Those rods have controlled (ideally) nuclear decay from their being in close proximity to other rods which generates a lot of heat, which is transferred to a separate cooling loop that boils water to make steam which drives an electric turbin…

I guess what I meant is that the overall concepts are understandable. Nuclear fuel gets hot, boils water, drives a turbine. For transmissions, different sized gears allow things to turn at different rates. But as soon as I dive into the details, I get lost. How exactly can you control the nuclear decay? How exactly does do the gears in the transmission move around and combine with eachother to create a specific gear…

Start here: https://www.youtube.com/watch?v=pWWjbnAVFKA

Scott Manley explains things so well. Highly recommended channel.

Re: Everything I Know About SSDs

#130

Post by JoshTriplett »

ascar wrote: post #75
wtallis wrote: post #62

Earlier quoted context omitted.

> However, I'm not seeing conclusive proof that modern HDDs show performance variation with respect to radius. They definitely still do; it's fundamental to drives that run at fixed RPM but maintain high areal density across the entire platter. One of the 1TB drives I have lying around does about 183MB/s at the beginning of the disk, 148MB/s in the middle, and 97MB/s at the end.

I'm really interested in how you benchmarked that? Is there a "simple" way to specify the physical location on a HD data should be written to?

> I'm really interested in how you benchmarked that?

You can benchmark disks, including seek time and speed at different points, using the tools "bogodisk" and "bogoseek": https://djwong.org/programs/bogodisk/

Post reply on HN