From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 781F81381F3 for ; Mon, 6 May 2013 17:34:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D5A73E08C5; Mon, 6 May 2013 17:34:24 +0000 (UTC) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7CCFEE0810 for ; Mon, 6 May 2013 17:34:23 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id ik5so1678029bkc.23 for ; Mon, 06 May 2013 10:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wbmCiHfoAm4TSVkAdiA5EHupIewjcZ3sjnDmfUj5Af8=; b=RyFrupHRQcnuzxyLyNBY2JmZVXOzeOF+H/LrFwKXJfSrMDVHbpZASlqOWxEY8Nl36s j4Ww2JyF6qVYO6A2Hl/IRWRYhrPk8FewluABZQiQBd9vgPnV9WDj6nEK4vI/pYgb9rfk NeJydRkhYRjGttvpejjiHmuWEV4dMg5nKqN6LjLtXCy1XFbb5x5lx7/29AN7A86z2idy 4xnAGuSw38/uDULawP3xHuuFlTapv05qJMiln4YXGxZ6YIIb27ldCJQDZ0GulU7ilRNc ImP9UMMDyQKHV06jVmr/LSuu3JEBmI9dZsNq3o4x476B335wYc4zVHjl/ZOjegSqw3k3 YA0w== X-Received: by 10.205.43.197 with SMTP id ud5mr8929960bkb.126.1367861661975; Mon, 06 May 2013 10:34:21 -0700 (PDT) Received: from [192.168.178.21] (p549C7F4F.dip0.t-ipconnect.de. [84.156.127.79]) by mx.google.com with ESMTPSA id jz9sm5665978bkb.1.2013.05.06.10.34.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 10:34:20 -0700 (PDT) Message-ID: <5187E99C.2030105@googlemail.com> Date: Mon, 06 May 2013 19:34:20 +0200 From: Volker Armin Hemmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130427 Thunderbird/17.0.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Recover on SSD References: <20130505161640.GB30557@BIFROST.fritz.box> <20130506110021.GB2702@BIFROST.zedat.fu-berlin.de> In-Reply-To: <20130506110021.GB2702@BIFROST.zedat.fu-berlin.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 167c6502-ade2-46c7-b141-d87cb8bd4dff X-Archives-Hash: bb666c580f9f2ec5df9172235b9ae5ca 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.