Re: [gentoo-user] Recover on SSD

[Randolph Maaßen]

2013/5/6 Alan McKinnon <alan.mckinnon@×××××.com>

> On 06/05/2013 20:36, Hinnerk van Bruinehsen wrote:
> > On Mon, May 06, 2013 at 07:34:20PM +0200, Volker Armin Hemmann wrote:
> >> emm - no. Wear leveling does not need any spare blocks. A lot of drives
> >> do have spare blocks, but those are never the same size of the original
> >> size (at least not on drives you can buy for a sensible amount of
> >> money).  More like 120+8 or 160+16 or 256+16.
> >>
> >> The spare blocks are used like on a hdd: some block goes bad, another
> >> one is mapped in.
> >>
> >> Since the sdd firmware does not know if something was deleted or not* -
> >> it does know shit about filesystems**, you can of course dd an image, if
> >> you want to. Just like on a hdd.
> >>
> >> *there are drives that do garbage collection without TRIM for fat and or
> >> ntfs.. so they seem to know a bit about filesystems.
> >>
> >> ** and this is why TRIM exists in the first place. To tell the drive:
> >> yes, this data is gone. You don't need to care about it anymore.
> >
> >
> > The actual numbers were made up to make the point (maybe I should have
> > stated that in my OP). According to [1] they are normally between 7% -
> > 37%.
> > Linux supports TRIM since Kernel 2.6.28. It's supported for several
> > filesystems (Ext4, Btrfs, FAT, GFS2 and XFS) but must be enabled via the
> > discard mount option. I don't have definitive information for Windows
> > but it seems to be supported by at least Windows 7 (as far as I can tell
> > without any user interaction).
> > Since the "deletion" happened under Windows I made a guess that it is
> > not totally unreasonable that dd may not work (if the deleted data would
> > have been "TRIMed").
> >
> >
> >
> > [1]
> http://www.lsi.com/downloads/Public/Flash%20Storage%20Processors/LSI_PRS_FMS2012_TE21_Smith.pdf
> >
>
>
>
> A delete on an SSD is a very expensive operation, to my mind it seems
> completely unreasonable to think that Windows would try and clear many
> tens of GB just because it trashed a partition table. It would take
> _hours_ to clear those blocks.
>
> By far the easiest route would be to just do what is done for spinning
> disks - write the partition table, leave whatever junk is in the cells
> intact until the partition is formatted and actual data is written to
> the fs.
>
> As your results show, this is indeed what did happen.
>
> --
> Alan McKinnon
> alan.mckinnon@×××××.com
>
>
>

Ok, let me sum up what I understood about the working of SSDs, please
correct me if I'm wrong at some point.

- The SSD stores what internal cell is allocated as a sector for the block
device representation on the SATA port.
- When a file is deleted the file system marks the block device sectors as
free and sends the TRIM command to the SSD and the SSD really frees the
underlying cell / breaks the cell - section allocation.
- Some SSDs have idle TRIM as described in http://en.wikipedia.org/wiki/TRIM to
use the advantage at systems that doesn't have the file system option
- A write operation can write to sectors which are not TRIMed jet

- When some program overwrites the partition table the sectors of the
partition aren't touched, so the SSD must be aware of the partition table
to trim these sectors
- A new partition can be formatted without trimming the sectors

- So when creating a new partition on the same sectors used before, the
sector cell allocation in the SSD is still the same, and no data is lost,
except the SSD is aware of the partition table to know which sectors can be
TRIMed



-- 
Mit freundlichen Grüßen / Best regards

Randolph Maaßen