[gentoo-user] Recover on SSD

[gentoo-user] Recover on SSD

[Randolph Maaßen]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Hi,

I have a SSD in my laptop and I am running Win7 and Gentoo in Parralel. for
some purpose I needed several Partitions so my base system was lying on
sda10, on an LVM-PV. Today my Windows refused to start and during recovery
its diskpart must have deleted the information about the 10th partition on
the disk, containing my main Gentoo system. Recovery failed, but
sysrescuecd still works :)

Now I'm concerned about the rescueing of the partition on the SSD, is it
the same way as on HDDs and are the same memory-parts of the SSD used? Or
is the partiton gone forever? And when I recreate a partition, will the PV
with the data still be there and readable?

-- 
Mit freundlichen Grüßen / Best regards

Randolph Maaßen

[-- Attachment #2: Type: text/html, Size: 881 bytes --]

Re: [gentoo-user] Recover on SSD

[Alan McKinnon]

On 05/05/2013 16:44, Randolph Maaßen wrote:
> Hi,
> 
> I have a SSD in my laptop and I am running Win7 and Gentoo in Parralel.
> for some purpose I needed several Partitions so my base system was lying
> on sda10, on an LVM-PV. Today my Windows refused to start and during
> recovery its diskpart must have deleted the information about the 10th
> partition on the disk, containing my main Gentoo system. Recovery
> failed, but sysrescuecd still works :)
> 
> Now I'm concerned about the rescueing of the partition on the SSD, is it
> the same way as on HDDs and are the same memory-parts of the SSD used?
> Or is the partiton gone forever? And when I recreate a partition, will
> the PV with the data still be there and readable?

Make a backup copy of the entire disk with one of the dd* apps around
then try it and see what happens.

Your question is not one that can really be answered better than
"maybe", so try it and see. The odds are on your side - Windows probably
just did what Windows does best (assume it's the only thing in the
universe) and trashed the partition table, not all the data on the disk.

However, do not run Windows or any software that will change the disk
except rescue utilities till you have rescued everything. Just in case
Windows _does_ decided to overwrite data



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Recover on SSD

[Volker Armin Hemmann]

Am 05.05.2013 16:44, schrieb Randolph Maaßen:
> Hi,
>
> I have a SSD in my laptop and I am running Win7 and Gentoo in
> Parralel. for some purpose I needed several Partitions so my base
> system was lying on sda10, on an LVM-PV. Today my Windows refused to
> start and during recovery its diskpart must have deleted the
> information about the 10th partition on the disk, containing my main
> Gentoo system. Recovery failed, but sysrescuecd still works :)
>
> Now I'm concerned about the rescueing of the partition on the SSD, is
> it the same way as on HDDs and are the same memory-parts of the SSD
> used? Or is the partiton gone forever? And when I recreate a
> partition, will the PV with the data still be there and readable?
>
> -- 
> Mit freundlichen Grüßen / Best regards
>  
> Randolph Maaßen
>
http://www.google.de/search?q=ssd+partition+recovery&client=safari&rls=x86_64&oe=UTF-8&oq=ssd+partition+recovery&gs_l=heirloom-serp.3..0j0i30j0i8i30l8.4222.5907.0.6812.8.7.1.0.0.0.80.476.7.7.0...0.0...1ac.1.12.heirloom-serp.XThCXzx_Xuk

good luck. Next time: backup first, fiddle around with partition tools
second.

Re: [gentoo-user] Recover on SSD

[Hinnerk van Bruinehsen]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

On Sun, May 05, 2013 at 02:44:11PM +0000, Randolph Maaßen wrote:
> Hi,
> 
> I have a SSD in my laptop and I am running Win7 and Gentoo in Parralel. for
> some purpose I needed several Partitions so my base system was lying on
> sda10, on an LVM-PV. Today my Windows refused to start and during recovery
> its diskpart must have deleted the information about the 10th partition on
> the disk, containing my main Gentoo system. Recovery failed, but
> sysrescuecd still works :)
> 
> Now I'm concerned about the rescueing of the partition on the SSD, is it
> the same way as on HDDs and are the same memory-parts of the SSD used? Or
> is the partiton gone forever? And when I recreate a partition, will the PV
> with the data still be there and readable?

You could try Testdisk[1]. It may help. 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. Even if it is, you'd lose any
information about directories or files (names, dates, accessrights and
so on).
You should definitly try to minimize writes (ideally there would be
none) since they can corrupt data. 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.
If you can't recover the old partition information I'd say you lost your
data unless you are willing (and there's no guarantees either) to pay
substantial amounts of money to specialised services (substantial as in
most likely >> 1000 EUR).

WKR
Hinnerk


[1] http://www.cgsecurity.org/wiki/TestDisk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Recover on SSD

[Randolph Maaßen]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

2013/5/5 Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de>

> On Sun, May 05, 2013 at 02:44:11PM +0000, Randolph Maaßen wrote:
> > Hi,
> >
> > I have a SSD in my laptop and I am running Win7 and Gentoo in Parralel.
> for
> > some purpose I needed several Partitions so my base system was lying on
> > sda10, on an LVM-PV. Today my Windows refused to start and during
> recovery
> > its diskpart must have deleted the information about the 10th partition
> on
> > the disk, containing my main Gentoo system. Recovery failed, but
> > sysrescuecd still works :)
> >
> > Now I'm concerned about the rescueing of the partition on the SSD, is it
> > the same way as on HDDs and are the same memory-parts of the SSD used? Or
> > is the partiton gone forever? And when I recreate a partition, will the
> PV
> > with the data still be there and readable?
>
> You could try Testdisk[1]. It may help. 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. Even if it is, you'd lose any
> information about directories or files (names, dates, accessrights and
> so on).
> You should definitly try to minimize writes (ideally there would be
> none) since they can corrupt data. 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.
> If you can't recover the old partition information I'd say you lost your
> data unless you are willing (and there's no guarantees either) to pay
> substantial amounts of money to specialised services (substantial as in
> most likely >> 1000 EUR).
>
> WKR
> Hinnerk
>
>
> [1] http://www.cgsecurity.org/wiki/TestDisk
>


Thanks for the input. I ensured that there is no write after I noticed the
partition was missing.
I try what I can now, and I'm sure its gonna be a long night


-- 
Mit freundlichen Grüßen / Best regards

Randolph Maaßen

[-- Attachment #2: Type: text/html, Size: 2726 bytes --]

Re: [gentoo-user] Recover on SSD

[Randolph Maaßen]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

2013/5/5 Randolph Maaßen <r.maassen60@gmail.com>

> 2013/5/5 Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de>
>
>> On Sun, May 05, 2013 at 02:44:11PM +0000, Randolph Maaßen wrote:
>> > Hi,
>> >
>> > I have a SSD in my laptop and I am running Win7 and Gentoo in Parralel.
>> for
>> > some purpose I needed several Partitions so my base system was lying on
>> > sda10, on an LVM-PV. Today my Windows refused to start and during
>> recovery
>> > its diskpart must have deleted the information about the 10th partition
>> on
>> > the disk, containing my main Gentoo system. Recovery failed, but
>> > sysrescuecd still works :)
>> >
>> > Now I'm concerned about the rescueing of the partition on the SSD, is it
>> > the same way as on HDDs and are the same memory-parts of the SSD used?
>> Or
>> > is the partiton gone forever? And when I recreate a partition, will the
>> PV
>> > with the data still be there and readable?
>>
>> You could try Testdisk[1]. It may help. 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. Even if it is, you'd lose any
>> information about directories or files (names, dates, accessrights and
>> so on).
>> You should definitly try to minimize writes (ideally there would be
>> none) since they can corrupt data. 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.
>> If you can't recover the old partition information I'd say you lost your
>> data unless you are willing (and there's no guarantees either) to pay
>> substantial amounts of money to specialised services (substantial as in
>> most likely >> 1000 EUR).
>>
>> WKR
>> Hinnerk
>>
>>
>> [1] http://www.cgsecurity.org/wiki/TestDisk
>>
>
>
> Thanks for the input. I ensured that there is no write after I noticed the
> partition was missing.
> I try what I can now, and I'm sure its gonna be a long night
>
>
>
> --
> Mit freundlichen Grüßen / Best regards
>
> Randolph Maaßen
>
>

I'm so damn lucky

I dd'ed the SSD onto an external drive and worked at first on the image
with qemu. A simple recreation of the partition brought the system back to
live on the image. I tried the same on the real machine and Gentoo works
again.


-- 
Mit freundlichen Grüßen / Best regards

Randolph Maaßen

[-- Attachment #2: Type: text/html, Size: 3632 bytes --]

Re: [gentoo-user] Recover on SSD

[Dale]

Randolph Maaßen wrote:
>
>
> I'm so damn lucky
>
> I dd'ed the SSD onto an external drive and worked at first on the
> image with qemu. A simple recreation of the partition brought the
> system back to live on the image. I tried the same on the real machine
> and Gentoo works again.
>
>
> -- 
> Mit freundlichen Grüßen / Best regards
>  
> Randolph Maaßen
>

Allow me to introduce what is likely the luckiest computer user there
is.  Here he is:  Randolph Maaßen

If that was me, I would have lost everything on there. 

Dale 

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Recover on SSD

[Gregory Shearman]

In linux.gentoo.user, Dale wrote:
> Randolph Maaßen wrote:
>>
>> I'm so damn lucky
>>
>> I dd'ed the SSD onto an external drive and worked at first on the
>> image with qemu. A simple recreation of the partition brought the
>> system back to live on the image. I tried the same on the real machine
>> and Gentoo works again.
>
> Allow me to introduce what is likely the luckiest computer user there
> is.  Here he is:  Randolph Maaßen
>
> If that was me, I would have lost everything on there. 

But you'd lose everything on there with style, Dale.

I don't trust any machine and therefore have multiple backups in
different places. I haven't lost anything.... yet.

-- 
Regards,
Gregory.

Re: [gentoo-user] Recover on SSD

[Dale]

Gregory Shearman wrote:
> In linux.gentoo.user, Dale wrote:
>> Randolph Maaßen wrote:
>>> I'm so damn lucky
>>>
>>> I dd'ed the SSD onto an external drive and worked at first on the
>>> image with qemu. A simple recreation of the partition brought the
>>> system back to live on the image. I tried the same on the real machine
>>> and Gentoo works again.
>> Allow me to introduce what is likely the luckiest computer user there
>> is.  Here he is:  Randolph Maaßen
>>
>> If that was me, I would have lost everything on there. 
> But you'd lose everything on there with style, Dale.
>
> I don't trust any machine and therefore have multiple backups in
> different places. I haven't lost anything.... yet.
>


I have backups of the things I really need.  I do that to run off the
evil spirits if nothing else.  We all know by now that if you don't have
backups, you will wish you did.  It never fails. 

Dale

:-)  :-) 


P. S.  I updated to grub2.  Yeppie!!!!  There is a Gentoo wiki that lets
you chain load with the old grub to make sure everything works.  Since
it worked for me, must be fool proof right?  ;?

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Recover on SSD

[Stroller]

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.

Stroller.

Re: [gentoo-user] Recover on SSD

[Hinnerk van Bruinehsen]

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

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.
This means two things: you can't really delete something securely
(noteven with tools like shred) and you can't access "overwritten" data
(because it's now inside the unused-marked area).

There is a special command (TRIM [1]) that does the marking after
something was deleted to counter perfomance degradation.

Fun fact: most SSDs that offer a "secure delete" feature (whole disk)
don't really delete anything but are internally encrypted and throw away
the encryption key and generate a new one on receiving the secure delete
command which leads to unreadable data and therefore is a kind of secure
deletion (unless the underlying crypto is broken).

WKR
Hinnerk

[1] http://en.wikipedia.org/wiki/TRIM

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Recover on SSD

[Paul Hartman]

On Sun, May 5, 2013 at 7:49 PM, Randolph Maaßen <r.maassen60@gmail.com> wrote:
> I'm so damn lucky
>
> I dd'ed the SSD onto an external drive and worked at first on the image with
> qemu. A simple recreation of the partition brought the system back to live
> on the image. I tried the same on the real machine and Gentoo works again.

Wow, congratulations.

In the old days when I first started using Linux, I used to keep a
backup of my boot sector and partition table on a floppy disk. Maybe I
should consider this practice again as part of my backup routine. :)

Re: [gentoo-user] Recover on SSD

[Volker Armin Hemmann]

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.

Re: [gentoo-user] Recover on SSD

[Hinnerk van Bruinehsen]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Recover on SSD

[Alan McKinnon]

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@gmail.com

Re: [gentoo-user] Recover on SSD

[Randolph Maaßen]

[-- Attachment #1: Type: text/plain, Size: 3701 bytes --]

2013/5/6 Alan McKinnon <alan.mckinnon@gmail.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@gmail.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

[-- Attachment #2: Type: text/html, Size: 5144 bytes --]

Re: [gentoo-user] Recover on SSD

[Stroller]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]


On 6 May 2013, at 21:07, Randolph Maaßen wrote:

> - 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.

So if I'm writing a new filesystem, I have to make sure it make the TRIM systemcall, otherwise it'll break with SSDs?

Is that the difference between SSDs and spinning magneto-platters?

Stroller.


[-- Attachment #2: Type: text/html, Size: 1296 bytes --]

Re: [gentoo-user] Recover on SSD

[Alan McKinnon]

On 07/05/2013 16:49, Stroller wrote:
> 
> On 6 May 2013, at 21:07, Randolph Maaßen wrote:
> 
>> - 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.
> 
> So if I'm writing a new filesystem, I have to make sure it make the TRIM
> systemcall, otherwise it'll break with SSDs?

No.

SSDs work with or without TRIM.

They just work much better with TRIM: cell erasure happens at a
convenient time rather than right in the middle of the next write to the
cell (which is almost always going to be the worst possible time to do it)


> 
> Is that the difference between SSDs and spinning magneto-platters?

No.

Think about this.

1. make an fs and use it a bit.
2. trash the fs and mkfs it again
3. SSD stops working

Hmmm. Facepalm epic fail at spectacular proportions.

Did you ever see that happen anywhere ever? No?
That's because it doesn't work that way.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Recover on SSD

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On 05/07/2013 10:49 AM, Stroller wrote:
> 
> On 6 May 2013, at 21:07, Randolph Maaßen wrote:
> 
>> - 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.
> 
> So if I'm writing a new filesystem, I have to make sure it make the TRIM
> systemcall, otherwise it'll break with SSDs?

Not exactly. What the TRIM system call really does is give the drive
hints about where the boundaries of your data really are, so that it
knows what parts of the disk's space it can take more liberties with.

As a rough analogy, imagine you're helping a friend fill a bunch of
crates. Perhaps the friend told you he doesn't really care about some of
the stuff, and you realize you can get stuff done more effectively by
dumping a crate full of junk into the trash and putting other stuff
(stuff he cares about) into it.

This helps improve disk lifetime and efficiency, but it's not strictly
necessary for functionality; nobody's truly harmed by having a crate of
junk hanging around, since the owner can always replace stuff in it at
their leisure, anyway. It's just more efficient if the crate's empty
when he goes to put stuff in it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]