Writing image to W7 SSD with XP

[Fokke Nauta]

Hi all,

Perhaps slightly OT but you guys know about XP as well ...

I have installed W7 64b in my workstation. To do so I installed a 120G SSD,
so I can take the full benefit of W7.
It's a multiboot system with 3 XP installations: the original XP system, an
audio system and a back-up system. With this back-up system I can make disk
images of the various Windows partitions, and write them back in case it is
needed when Windows gets crippled. With XP I needed to do this a few times.
With W7 on the SSD it is no problem to make a disk image, but can I ever
write this back to the SSD with this XP system? Won't I damage the SSD as XP
won't recognize this disk as an SSD and don't know the TRIM command?

Thanks beforehand for your answers.

Fokke Nauta

 

[Paul]

Hi all,

Perhaps slightly OT but you guys know about XP as well ...

I have installed W7 64b in my workstation. To do so I installed a 120G SSD,
so I can take the full benefit of W7.
It's a multiboot system with 3 XP installations: the original XP system, an
audio system and a back-up system. With this back-up system I can make disk
images of the various Windows partitions, and write them back in case it is
needed when Windows gets crippled. With XP I needed to do this a few times.
With W7 on the SSD it is no problem to make a disk image, but can I ever
write this back to the SSD with this XP system? Won't I damage the SSD as XP
won't recognize this disk as an SSD and don't know the TRIM command?

Thanks beforehand for your answers.

Fokke Nauta

You can restore an SSD to close to factory state, by using a Secure Erase command.
Then, copy over the data. Things not removed by Secure Erase, are records of
bad blocks, or of the wear state (percentage of wear). Those should be properly
preserved (as part of the lifetime state of the SSD). But in terms of tracking
state of usage, all the blocks should go back in the pool of available blocks.
This is not the same thing as a Format, and the side effects are entirely
different with an SSD (as it causes the pool of available blocks to be
properly populated). Just writing zeros over the entire drive, is not
the same thing. I couldn't use "dd if=/dev/zero" to simulate a Secure Erase.

http://forums.overclockersclub.com/index.php?showtopic=184250

An actual Secure Erase utility is available here. It will issue the
single ATA/ATAPI command, to tell the drive to erase itself. One of the
staff here, helped prepare the Secure Erase option as a proposal to
the standards committee. Secure Erase was originally added to IDE and
SATA drives. And apparently, is not available on SCSI, although that
could certainly change with time (SCSI has its own standards). Support
for that function, in an SSD, should exist as the SSD also has
to adhere to some version of ATA spec.

http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml

Rather than just use the utility, you should also read their documentation
as well. It's important to understand how it works, and what roadblocks
you can run into (disk password handling). If you set a password on the
drive, as part of the procedure, use a pen and write the password
on the drive exterior.

Now that the drive is Secure Erased, you can think about doing the restore.

When you restore from backup, you'll be doing write operations. I don't
think there would be a reason to be issuing TRIM while that is happening,
so TRIM support shouldn't matter during the restoration. Once you're booted
into the restored OS, then TRIM support could matter, in terms of
effective garbage collection. If the restoration was .vhd based, only
the sectors holding data need be written back, and no unnecessary writes
should result. So the Windows 7 System Image, as an example, should be
100% efficient during restoration. I can't vouch for any other
kinds of restore (such as NTBackup perhaps). Macrium Reflect, as far
as I know, works the same as Windows 7. And it helps, if the setup
has the proper alignment (which is supposedly a given, with Windows 7,
but not likely to be true with WinXP, with exceptions). If you just
installed WinXP on an SSD, without any considerations at all for alignment,
that's not going to work very well in terms of alignment (as WinXP is
CHS based, and aligns to 63 sectors). There are tools and ways to fix that,
which you should have done, before backing up the drive.

Much has been written about the care and feeding of SSDs, and we really
shouldn't need to write anything more about it. There are tutorials out
there. It's a *lot* of work to read all of them, but all part of
owning an SSD and taking care of it.

I don't own an SSD, which is why I have no particular need of the knowledge
right now.

I've only tested Secure Erase on a hard drive here, and didn't have a
problem using the CMRR utility. The disk worked afterwards. The only
thing wrong with my experiment, was I wasn't around to witness exactly
when the command completed. So I don't know how close to maximum writing
speed it is. (The command runs completely inside the drive, and the CPU
on the computer has nothing to do about it. What I wanted to know, is
if the disk writes at 125MB/sec say, whether the Secure Erase also
runs at 125MB/sec. It should, but I wasn't around to verify the
execution time.)

Paul

 

[Fokke Nauta]

You can restore an SSD to close to factory state, by using a Secure Erase
command.
Then, copy over the data. Things not removed by Secure Erase, are records
of
bad blocks, or of the wear state (percentage of wear). Those should be
properly
preserved (as part of the lifetime state of the SSD). But in terms of
tracking
state of usage, all the blocks should go back in the pool of available
blocks.
This is not the same thing as a Format, and the side effects are entirely
different with an SSD (as it causes the pool of available blocks to be
properly populated). Just writing zeros over the entire drive, is not
the same thing. I couldn't use "dd if=/dev/zero" to simulate a Secure
Erase.

http://forums.overclockersclub.com/index.php?showtopic=184250

An actual Secure Erase utility is available here. It will issue the
single ATA/ATAPI command, to tell the drive to erase itself. One of the
staff here, helped prepare the Secure Erase option as a proposal to
the standards committee. Secure Erase was originally added to IDE and
SATA drives. And apparently, is not available on SCSI, although that
could certainly change with time (SCSI has its own standards). Support
for that function, in an SSD, should exist as the SSD also has
to adhere to some version of ATA spec.

http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml

Rather than just use the utility, you should also read their documentation
as well. It's important to understand how it works, and what roadblocks
you can run into (disk password handling). If you set a password on the
drive, as part of the procedure, use a pen and write the password
on the drive exterior.

Now that the drive is Secure Erased, you can think about doing the
restore.

When you restore from backup, you'll be doing write operations. I don't
think there would be a reason to be issuing TRIM while that is happening,
so TRIM support shouldn't matter during the restoration. Once you're
booted
into the restored OS, then TRIM support could matter, in terms of
effective garbage collection. If the restoration was .vhd based, only
the sectors holding data need be written back, and no unnecessary writes
should result. So the Windows 7 System Image, as an example, should be
100% efficient during restoration. I can't vouch for any other
kinds of restore (such as NTBackup perhaps). Macrium Reflect, as far
as I know, works the same as Windows 7. And it helps, if the setup
has the proper alignment (which is supposedly a given, with Windows 7,
but not likely to be true with WinXP, with exceptions). If you just
installed WinXP on an SSD, without any considerations at all for
alignment,
that's not going to work very well in terms of alignment (as WinXP is
CHS based, and aligns to 63 sectors). There are tools and ways to fix
that,
which you should have done, before backing up the drive.

Much has been written about the care and feeding of SSDs, and we really
shouldn't need to write anything more about it. There are tutorials out
there. It's a *lot* of work to read all of them, but all part of
owning an SSD and taking care of it.

I don't own an SSD, which is why I have no particular need of the
knowledge
right now.

I've only tested Secure Erase on a hard drive here, and didn't have a
problem using the CMRR utility. The disk worked afterwards. The only
thing wrong with my experiment, was I wasn't around to witness exactly
when the command completed. So I don't know how close to maximum writing
speed it is. (The command runs completely inside the drive, and the CPU
on the computer has nothing to do about it. What I wanted to know, is
if the disk writes at 125MB/sec say, whether the Secure Erase also
runs at 125MB/sec. It should, but I wasn't around to verify the
execution time.)

Paul

Hi Paul,

Thanks for your quick and very extensive reply.
Using a SSD is not so straightforward as I thought.
I have an application to wipe disks and is has an algorhythm for secure
erase.
But I always thought you should not secure erase (wipe) a SSD because of the
extra wearing it causes. So this procedure makes me a bit uncertain.

Fokke

 

[Paul]

Hi Paul,

Thanks for your quick and very extensive reply.
Using a SSD is not so straightforward as I thought.
I have an application to wipe disks and is has an algorhythm for secure
erase.
But I always thought you should not secure erase (wipe) a SSD because of the
extra wearing it causes. So this procedure makes me a bit uncertain.

Fokke

How often do you do a restoration from backup ?

The total number of writes to an SSD are limited in any case, and
lots of other things you're doing, are slowly wearing out the flash
chips.

On a typical flash chip today, on a cheap SSD, you get 3000 writes
per flash location. On most days, you won't be writing to every
location on the SSD. So most of the time, what you're doing isn't
injurious to the drive. But you cannot treat the SSD with the same
abandon as with a regular hard drive. On a regular hard drive,
time is the enemy typically, rather than writes. With exceptions,
such as usage on a server with continuous read/write and head
movement. Where the hard disk drive won't last nearly as long.

You can wear out an SSD, simply by accident, by going on a long
vacation, and leaving a program running which does nothing but
writes. A hard drive would survive such a mistake, whereas the SSD
might not.

Paul

 

[BillW50]

In Paul typed on Thu, 06 Sep 2012 10:48:47 -0400:

How often do you do a restoration from backup ?

The total number of writes to an SSD are limited in any case, and
lots of other things you're doing, are slowly wearing out the flash
chips.

On a typical flash chip today, on a cheap SSD, you get 3000 writes
per flash location. On most days, you won't be writing to every
location on the SSD. So most of the time, what you're doing isn't
injurious to the drive. But you cannot treat the SSD with the same
abandon as with a regular hard drive. On a regular hard drive,
time is the enemy typically, rather than writes. With exceptions,
such as usage on a server with continuous read/write and head
movement. Where the hard disk drive won't last nearly as long.

You can wear out an SSD, simply by accident, by going on a long
vacation, and leaving a program running which does nothing but
writes. A hard drive would survive such a mistake, whereas the SSD
might not.

Paul

I was a bit concern about the longevity of SSD life at first too. And I
only buy SLC SSD and not MLC SSD. Which SLC lasts over 100,000 writes
per cell. But I eliminated most of the unnecessary writes from Windows.
Then I monitored the number of writes Windows did in an average day. And
I averaged about 300MB per day. And I forgot whether I figured this for
a 4GB or a 8GB SSD. But it came out something like the SSD wouldn't hit
100,000 writes per cell until 8,000 years later. Then I stopped worrying
about it. By the way, even my 5 year old SLC SSD are still working just
fine. Only 7,995 years left in them to go. ;-)

 

[Fokke Nauta]

How often do you do a restoration from backup ?

Well, with XP it happened quite a few times. Let's say 10 times in 4 years.
With W7 I don't know yet.

The total number of writes to an SSD are limited in any case, and
lots of other things you're doing, are slowly wearing out the flash
chips.

I use the SSD only for the system partition of W7. Only W7 and the
applications are installed there.
Temp directories are on another partition, and so are all data. And so is
the page file.

On a typical flash chip today, on a cheap SSD, you get 3000 writes
per flash location.

I have a Kingston Hyper X SH100S3 of 120G.
Not the cheapest one. It has 3 years warranty.

On most days, you won't be writing to every
location on the SSD. So most of the time, what you're doing isn't
injurious to the drive. But you cannot treat the SSD with the same
abandon as with a regular hard drive. On a regular hard drive,
time is the enemy typically, rather than writes. With exceptions,
such as usage on a server with continuous read/write and head
movement. Where the hard disk drive won't last nearly as long.

You can wear out an SSD, simply by accident, by going on a long
vacation, and leaving a program running which does nothing but
writes. A hard drive would survive such a mistake, whereas the SSD
might not.

That's the worst thing one could do.
I'm not afraid of that. When I'm on vacation, all systems are down.

Fokke

 

[Fokke Nauta]

In Paul typed on Thu, 06 Sep 2012 10:48:47 -0400:

I was a bit concern about the longevity of SSD life at first too. And I
only buy SLC SSD and not MLC SSD. Which SLC lasts over 100,000 writes per
cell. But I eliminated most of the unnecessary writes from Windows. Then I
monitored the number of writes Windows did in an average day. And I
averaged about 300MB per day. And I forgot whether I figured this for a
4GB or a 8GB SSD. But it came out something like the SSD wouldn't hit
100,000 writes per cell until 8,000 years later. Then I stopped worrying
about it. By the way, even my 5 year old SLC SSD are still working just
fine. Only 7,995 years left in them to go. ;-)

Thanks, this puts me a bit to ease.
Though I bought the Kingston Hyper X, it says "SandForce controller
technology with premium NAND Flash", so I don't know whether it's SLC or
MLC. The latter, I think.
But I only use it as the W7 partition with the applications. Data, Temp
drive and page file are all on other partitions.
If it will last for 5 years, the rest of my PC will be ancient again.
And in 40 years I won't be here either

Fokke

 

[BillW50]

In

Thanks, this puts me a bit to ease.
Though I bought the Kingston Hyper X, it says "SandForce controller
technology with premium NAND Flash", so I don't know whether it's SLC
or MLC. The latter, I think.
But I only use it as the W7 partition with the applications. Data,
Temp drive and page file are all on other partitions.
If it will last for 5 years, the rest of my PC will be ancient again.
And in 40 years I won't be here either

Fokke

You know a lot of those come with a lifetime warrantee. My Kingston SDHC
ones I think came with lifetime. I don't know if they do the same for
their SSDs or not? Yes the predicted life of time depends on the amount
of writing you do with them. And I seem to recall I figured if I
constantly wrote to mine 24/7 as fast as it could write, I would get a
short two years out of them. But then again, if you are writing that
much, why bother with SSDs in the first place?

Yes, most manufactures don't tell you anymore if they are MLC or SLC
types. SLC types only cost twice as much to manufacture, so you would
think they would bother to tell you since SLC type can write 10 times or
more than MLC. I also feel if you got 5 years of service out of a SSD,
you got your moneys worth too. ;-)