Live data from Hacker News

Everything I Know About SSDs

kcall.co.uk

51–60 of 190 posts

Re: Everything I Know About SSDs

#51
post #3

I was under the impression that if you do not encrypt an SSD from the first use, then any attempt at overwriting with 0s is futile, as well as any other method to securely delete the files. The files will be easily recovered. This guy seems to say the opposite, in that the files are "simply not there anymore", contrary to everything I've read: who's right here?

The big problem with erasing SSDs is that when you think you're overwriting something you're actually writing new blocks (because of the translation layer). How many iterations do you have to do before you're certain to have actually hit every physical block? Nobody knows. Maybe infinite. Non-zero data blocks might not be readable through the flash drive's front-end interface, but they're still sitting there on the a…

One iteration of grinding the drive to fine powder/melting it down should be enough. Anything else might be insufficient.

Re: Everything I Know About SSDs

#52
post #37

There are a few technologies that I’ve tried very earnestly to understand, only to find out that it’s basically black magic and there’s no use in trying to understand it. Those things are modern car transmissions, nuclear reactors, and SSDs.

There's a pretty succinct (2 minute) non-engineering description of how a nuclear reactor works in the Chernobyl miniseries you might want to check out: https://www.youtube.com/watch?v=BpwU4mtWXAE

Why is that scene so pointlessly edgy? Is the whole show like that?

Re: Everything I Know About SSDs

#54

"As for writes, at 1 gb a day - far more than my current rate of data use - it would take the same 114 years to reach 40 tb." Maybe it works for author's very specific system or use-case, but on my personal MBP laptop with very occasional usage pattern--some days I do not use it at all during the week--I end up with 10 GB per day of writes on average. That way it will be 11.4 years already, not so many. And I do not…

How much RAM do you have? And how many Chrome tabs?

Re: Everything I Know About SSDs

#55

There are a few technologies that I’ve tried very earnestly to understand, only to find out that it’s basically black magic and there’s no use in trying to understand it. Those things are modern car transmissions, nuclear reactors, and SSDs.

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…

Ok, I've studied the Flash storage (most SSDs these days) technolgy and can be understood like this:

* At the "lowest" level, there's a little cell that it's very much an EEPROM (but better, because newer tech). This little cell can hold 1, 2, 3 or 4 bits, depending on gen/tech.

* You group a bunch on those cells together and they form a page. Usually it's 1024 cells a page.

* You group a bunch of pages together and they form a block (don't confuse with "block" as in "block oriented device"). Blocks are usually made of 128 pages.

* You group a bunch (1024 usually) of blocks together and you get a plane.

* You get your massive storage by grouping a lot of planes together. Think of it as small (16-64 MB) storage devices that you connect in a RAID-like manner.

* Operations are restricted because of technology. On an individual level, cells can only be "programmed", that is, a 1 can bit flipped into a 0, but a 0 cannot be made a 1.

* If you need to turn a 0 into a 1, then you must do it on a block level (yep, 128 pages at a time).

* That's where the Flash Translation Layer kicks in: it's a mapping between the (logical) sectors (512b or 4096b) and the underlying mess. The FTL tells you how you form the sectors (which would be the blocks of a "block oriented device", but I'm trying to avoid that word).

* You also have "overprovisioning" at work - that is, if your SSD is 120gb, it's actually 128GB inside, but there's 8GB you don't get access (not even at the OS level), that the device uses to move things around.

* Wear Leveling/Garbage Collection mechanisms work to prevent individual cells from being used too much. Garbage Collection makes sure (or tries) that there are always enough "ready to program" cells around.

* The firmware makes everything work transparently to the world above it.

That would be a very (very very) simple explanation of how Flash storage works. Things like memory cards and thumb drives usually don't get overprovisioning nor wear leveling.

Re: Everything I Know About SSDs

#56
post #51

Earlier quoted context omitted.

The big problem with erasing SSDs is that when you think you're overwriting something you're actually writing new blocks (because of the translation layer). How many iterations do you have to do before you're certain to have actually hit every physical block? Nobody knows. Maybe infinite. Non-zero data blocks might not be readable through the flash drive's front-end interface, but they're still sitting there on the a…

One iteration of grinding the drive to fine powder/melting it down should be enough. Anything else might be insufficient.

That's a good way to erase a disk, but horrendously expensive if all you want to erase is a single file.

Re: Everything I Know About SSDs

#57

The part about filesystems is slightly incorrect. > The way the file system handles this is incompatible with the workings of NAND flash. That's true of most conventional filesystems, but log-structured filesystems are much more flash-friendly. That's why there has been a resurgence of interest in them, and also why a typical flash translation layer bears a striking resemblance to a log-structured FS. There are also…

> to an HDD all sectors are the same. Also I believe some humans, and (filesystems?) intentionally stored certain data towards the inside/outside of the HDD because the simple cylinder geometry allowed faster reads in those regions. However, I'm not seeing conclusive proof that modern HDDs show performance variation with respect to radius.

Io schedulers would also understand the geometry and reorder commands to minimize seek distance (and therefore seek time).

Re: Everything I Know About SSDs

#58

Earlier quoted context omitted.

Reader view helps a lot, and with such a simple website it is guaranteed to give a good result.

Not just a lot, it actually makes it readable. However I do feel this article needs a few graphs and diagrams. I've written [0] about data recovery and SSD/Flash storage is a massive beast to tackle even with diagrams to give you a vague idea of what's going on. [0] in old fashioned tree-based paper, unfortunately

Is there an available method to acquire some of these marked-up dead trees?

Re: Everything I Know About SSDs

#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" drives (perhaps from two different manufacturers)?

The prices look similar either way.

Re: Everything I Know About SSDs

#60
> The OCZ Myth: [...] with one overwrite pass of zeroes [...] A sort of RETRIM before that was invented.

It wasn't a myth, that was the idea all along.

> SSD Defragmentation [...]

An important factor left out is wear leveling, it doesn't make as much sense to arrange data in "file-system-order" when the bits on the drive move around.

Post reply on HN