I guess you missed my use of quote marks around the TLA ("LLF").
Even a "Full Format" on any HDD won't wipe any sectors clean other than rewriting sectors involved in the FS metadata. In this case, the formatting routine simply test reads each allocation unit's worth of sectors, discarding the data itself but noting any read errors flagged by the drive's controller in order to update the bad clusters map.
Is the right answer! :-)
Far more complicated for SSDs:
SSDs have a "write block size", typically about 4KB (though these numbers increase as technology develops) and an "erase block size", typically
256kB). Write blocks cannot be overwritten, the only way to re-use one is to erase the whole of the erase block it is in.There is a microcontroller in the SSD which keeps a internal mapping of logical blocks (as the computer's operating systems sees them) to the internal layout. Blocks are written to one erase block until it is full. Then all blocks that the microcontroller knows are still in use (hence the requirement for a "trim" command) are copied to another erase block and the whole erase block is cleared (to all ones). Erase blocks have a very short lifetime (sometimes, for MLC/TLC, as low as a few hundred erases). SSDs, therefore are highly over-provisioned with many spare erase blocks. If a block starts showing lots of errors, it will be retired, leaving its data intact, after having been copied to a new block.
The flash in an SSD can be de-soldered and read with cheap hardware.
The only way to be sure that all data has been destroyed is by physical destruction (angle grinder?).
If you are paranoid about the data, SSDs are not for you, or you need to only write encrypted data to them in the first place. If you are not worried by that, then you can more effectively write zeros over them all by issuing an ATA TRIM or SCSI UNMAP command to them covering the whole drive, which is pretty instant (at least compared with writing zeros to the whole drive) and it allows the drive to reorder the logical blocks to get back to full speed performance. Some drives support a secure erase, but at the bottom level, NAND flash cells fail by becoming unerasable/unwritable (rather than unreadable), so if you can bypass the drive's firmware, you will still be able to read data from all the worn out cells at least.
There's potentially a similar problem with hard drives, but you can overcome some of the SSD limitations by overwriting the drive twice, but before the second time you clear the grown defect list so you overwrite the mapped out sectors too. There are circumstances when that won't work (such as corrupt sector header so the sector can't be found), but such a sector is significantly harder to read anyway.
It's just a question of the skills and/or money available. Also, there's a very big difference between the effort involved to get an array back working as a filesystem with its application, or just getting back all the data to look through it for email addresses, credit card details, etc. without repairing the filesystem structures - the latter is dead easy.
OK, perhaps "exactly" wasn't a good choice of word, but the principle is the same for both technologies, there will be blocks containing data that you can no longer get at to overwrite ...
No different with a hard disk surely?
Have they really got that low? Last time I looked, MLC endurance was around 10,000 while SLC was around 100,000.
Doesn't all this SSD discussion imply that there needs to be a "zap it" mechanism built-in to the SSD devices themselves? Something that can be triggered and provide positive assurance that zapping has taken place successfully - and quite possibly requiring physical access, not just software control over the bus.
Hard discs don't have erase blocks, so no need to copy data between them, and no need for wear levelling either (usually).
| SanDisk's SMART Storage unit estimates TLC SSDs with the 1X cell | geometry that Samsung is using have an approximate 500 phase/erase | cycle limit. That is, you write to them 500 times but after that, game | over, the cell's dead.
| In 2012 Anandtech reckoned 2X geometry NAND had approximately 100,000 | P/E cycles, MLC flash had 3,000 and TLC flash had 1,000 to 1,500. It | might be 500-750 cycles with 1X-class NAND.
Better still, full disc encryption, either in hardware (some USB sticks come with it, as do many (most?) SSDs) or in the operating system.
No - that would be good as an "as well". We want to be able to take a pulled SSD, which might no longer function within a computer or as a USB storage device, apply a voltage and do something like press a button, wait n seconds, see a tiny LED light flashing to confirm chips have been zapped. No LED lighting up = time for hammer.
P.S. Shingled hard discs are an entirely different kettle of fish.
It's much less of an issue with HDDs due to their extremely parsimonious allocation of 'spare sectors' for remapping bad sectors, typicaly just one or two thousand, representing less than a hundredth of a percent of the total disk space. SSDs typically allocate several percent, in some cases allocating as much as ten percent or more to this function.
Regarding the bad tracks label on ancient 17 sectors per track HDDs, a blank list simply meant it was defect free. The defects, if any, being printed by the test formatting quality assurance process used by the manufacturer. The high level full format would detect any bad sectors and add the effected allocation units to its own bad clusters list. The information on the label was purely of academic interest alone.
The later IDE drives stored this defect list, generated by the factory only LLF phase of production, in the controller's NVRAM so it could 'silently' skip around defects. However, this skipping around defects wasn't entirely silent in the case of cheap brands of IDE HDDs during a high level full format.
The extra seek activity could be heard over and above the steady track to track seek as each defective sector was reached. If you were concerned about the quality of the particular example you were commissioning, it paid you to stay within earshot during the formatting process to listen out for such evidence of less than perfect media.
I think Excelstor (or similarly named cheapies) often exhibited this formatting behaviour giving you some forewarning of what to expect out of the drive during everyday use.
Depends on the O/S in use, Netware used to prompt you for the entries from the printed defect list, before it went on to do it's own compsurf (comprehensive surface analysis) of the disc, that usually took most of a weekend even for a couple of hundred MB.
Very different.
In a hard disk, sector 0 will be at the beginning, sector N will be at (subject to spared sectors/tracks) at a location found by dividing N by the number of heads and the number of sectors per track (1).
On an SSD when a sector is written it'll be put in the next empty block. When it's written again it'll be put in the next empty block - which will almost certainly not be the same one.
Andy
What I mean is that a processor within the hard drive (similar to the processor within the SSD) is the only thing that *truly* knows which logical sector is stored where, due to the mapping that's hidden in both cases - the point being that the O/S is unaware where the data is and can't guarantee to overwrite it.
There is a good chance that his Halifax login ID is automagically populated from a cookie on the machine that he regularly uses. Assuming he has ticked the "remember me on this PC" box.
Make a note of the initial ID tag before you zap things. This can also be an annoyance if you use an aggressive cookie and registry cleaner.
Even with HDDs measured in mere hundreds of MBs, life was just too short for such nonsense. I suspect that trying to run the same compsurf algorithm on a modern 4TB HDD would leave you with an obsolescent drive by the time it had finished the test.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.