From: Volker Armin Hemmann <volkerarmin@googlemail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Recover on SSD
Date: Mon, 06 May 2013 19:34:20 +0200 [thread overview]
Message-ID: <5187E99C.2030105@googlemail.com> (raw)
In-Reply-To: <20130506110021.GB2702@BIFROST.zedat.fu-berlin.de>
Am 06.05.2013 13:00, schrieb Hinnerk van Bruinehsen:
> On Mon, May 06, 2013 at 07:50:52AM +0100, Stroller wrote:
>> On 5 May 2013, at 17:16, Hinnerk van Bruinehsen wrote:
>>> ... The data on a SSD is not
>>> necessarily stored linar so it's not said that a new partition is using
>>> the same memory cells as the old one.
>>> …
>>> For a HDD I'd advise to create a copy
>>> using dd but from my understanding of SSD technology it's not
>>> guaranteed to copy the right (now unused marked) blocks.
>> Is anyone able to elaborate on this, please?
>>
>> 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.
>>
>> Surely flash memory devices must present themselves to the o/s as block devices, because that's how all storage devices work, right?
>>
>> 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.
> The problem is that you can't delete on a flash cell. The process is
> simplified: read cell - delete to be deleted stuff in memory - write
> memory contents back.
>
> Since flash cells can only be written to a fixed amount of times
> (afterwards they become unreliable) there is a concept called wear
> leveling. This means essentially that your 128 GB flash drive in reality
> hasn't just 128 GB of storage but e.g. 256GB. To spread out the writes
> it reads one cell, does the memory operation and write the contents back
> to another cell while marking the old cell as unused.
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.
next prev parent reply other threads:[~2013-05-06 17:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-05 14:44 [gentoo-user] Recover on SSD Randolph Maaßen
2013-05-05 16:11 ` Alan McKinnon
2013-05-05 16:11 ` Volker Armin Hemmann
2013-05-05 16:16 ` Hinnerk van Bruinehsen
2013-05-05 19:36 ` Randolph Maaßen
2013-05-06 0:49 ` Randolph Maaßen
2013-05-06 4:50 ` Dale
2013-05-06 15:18 ` Paul Hartman
2013-05-06 6:50 ` Stroller
2013-05-06 11:00 ` Hinnerk van Bruinehsen
2013-05-06 17:34 ` Volker Armin Hemmann [this message]
2013-05-06 18:36 ` Hinnerk van Bruinehsen
2013-05-06 18:57 ` Alan McKinnon
2013-05-06 20:07 ` Randolph Maaßen
2013-05-07 14:49 ` Stroller
2013-05-07 14:56 ` Alan McKinnon
2013-05-07 14:57 ` Michael Mol
[not found] <l68qd-4Mf-7@gated-at.bofh.it>
[not found] ` <l69Pj-6Bu-11@gated-at.bofh.it>
[not found] ` <l6cWR-1TQ-13@gated-at.bofh.it>
[not found] ` <l6hWy-84A-11@gated-at.bofh.it>
[not found] ` <l6lGN-4fF-1@gated-at.bofh.it>
2013-05-06 5:16 ` Gregory Shearman
2013-05-06 5:29 ` Dale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5187E99C.2030105@googlemail.com \
--to=volkerarmin@googlemail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox