| 1 |
On Mon, May 06, 2013 at 07:50:52AM +0100, Stroller wrote: |
| 2 |
> |
| 3 |
> On 5 May 2013, at 17:16, Hinnerk van Bruinehsen wrote: |
| 4 |
> > ... The data on a SSD is not |
| 5 |
> > necessarily stored linar so it's not said that a new partition is using |
| 6 |
> > the same memory cells as the old one. |
| 7 |
> > … |
| 8 |
> > For a HDD I'd advise to create a copy |
| 9 |
> > using dd but from my understanding of SSD technology it's not |
| 10 |
> > guaranteed to copy the right (now unused marked) blocks. |
| 11 |
> |
| 12 |
> Is anyone able to elaborate on this, please? |
| 13 |
> |
| 14 |
> I think I've had a eureka! moment of understanding whilst preparing to compose this reply, but I've always been sceptical of these kinds of statements in the past. |
| 15 |
> |
| 16 |
> Surely flash memory devices must present themselves to the o/s as block devices, because that's how all storage devices work, right? |
| 17 |
> |
| 18 |
> If I'm now understanding correctly, SSDs present themselves to the o/s as block devices more or less as convenient or necessary. They can be treated as such as long as all the data required is listed in the file allocation table. I'm left wondering how the SSD knows that a file has been deleted, and whether this works for all conceivable file-systems. |
| 19 |
|
| 20 |
The problem is that you can't delete on a flash cell. The process is |
| 21 |
simplified: read cell - delete to be deleted stuff in memory - write |
| 22 |
memory contents back. |
| 23 |
|
| 24 |
Since flash cells can only be written to a fixed amount of times |
| 25 |
(afterwards they become unreliable) there is a concept called wear |
| 26 |
leveling. This means essentially that your 128 GB flash drive in reality |
| 27 |
hasn't just 128 GB of storage but e.g. 256GB. To spread out the writes |
| 28 |
it reads one cell, does the memory operation and write the contents back |
| 29 |
to another cell while marking the old cell as unused. |
| 30 |
This means two things: you can't really delete something securely |
| 31 |
(noteven with tools like shred) and you can't access "overwritten" data |
| 32 |
(because it's now inside the unused-marked area). |
| 33 |
|
| 34 |
There is a special command (TRIM [1]) that does the marking after |
| 35 |
something was deleted to counter perfomance degradation. |
| 36 |
|
| 37 |
Fun fact: most SSDs that offer a "secure delete" feature (whole disk) |
| 38 |
don't really delete anything but are internally encrypted and throw away |
| 39 |
the encryption key and generate a new one on receiving the secure delete |
| 40 |
command which leads to unreadable data and therefore is a kind of secure |
| 41 |
deletion (unless the underlying crypto is broken). |
| 42 |
|
| 43 |
WKR |
| 44 |
Hinnerk |
| 45 |
|
| 46 |
[1] http://en.wikipedia.org/wiki/TRIM |
Archives