Which SSD?

En el artículo , Gene
Wirchenko escribió:

I have had memory sticks that did go bad.

*sigh*

RAM and flash memory are /completely/ different things. You're
comparing apples and oranges. Go do some reading up.

An SSD has an integrated controller that detects and maps out bad flash
blocks in the background, so they never become visible to the OS. RAM
doesn't.

On an SSD, a store of spare blocks is kept and used to replace bad ones.
This is why you often see SSD sizes in less than a full binary multiple:
e.g. 120GB, for 128, 240GB for 256, etc. The 'missing' bit is the spare
store. "Full capacity" SSDs use an additional flash chip, not part of
the main storage, for the spares.

When the SSD controller detects a bad flash block, it copies the data
(hopefully intact) from it to a spare, then maps out the bad block so it
isn't re-used. This happens transparently in the background. The host
computer is unaware it is even going on.

When the controller runs out of spare blocks to substitute for bad ones,
it should make the whole thing permanently read-only. If it didn't do
this, it would be forced to use bad flash memory for storage, corrupting
user data. The better makes of SSD (Intel, for example) will go read-
only, the cheaper ones from fly-by-night Chinese suppliers you've never
heard of may go read-only or may suddenly just stop working altogether,
taking your data with them.

When an SSD goes read-only, it's gently telling you it is worn out and
it's time to copy the data off onto a replacement. Yes, SSDs do wear
out. The flash cells, depending on their type, are only rated for a
certain number of writes.

The SMART data from an SSD includes a "wear level" indicator that tells
you the estimated remaining life of the SSD - based on the number of
spare flash blocks remaining. You /cannot/ determine it with tools like
HD Tune's scan tool, which is where we came in.

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

En el artículo , Ed Cryer
escribió:

No time wasted at all.

Yep, wasted. See my reply to Gene Wirchenko for an explanation.

HD Tune works well with SSDs

It's "HD Tune", not "SSD Tune".

Use the right tool for the job. Free hint: google SSDLife.

; whether it reports
them as blocks or sectors.

Irrelevant.

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

Mike Tomlinson wrote:
En el artÃ*culo , Ed Cryer
escribió:

No time wasted at all.

Yep, wasted. See my reply to Gene Wirchenko for an explanation.

HD Tune works well with SSDs

It's "HD Tune", not "SSD Tune".

Use the right tool for the job. Free hint: google SSDLife.

; whether it reports
them as blocks or sectors.

Irrelevant.


Thanks for that. I appreciate it. Forgive my ignorance. I had no idea
about all that.
It sounds extremely hazardous, as if an SSD could fail at any minute
without warning. I'm taking regular images of the thing, and keeping
three generations.

I have Samsung Magician, which I've used to optimise its performance;
updated firmware, applied RAPID Mode, run the OS Optimisation in which
it disabled hibernation & radically reduced the paging file.

Magician reports health as "Good" and "6.46TB written".
Would you recommend running some independent analysis?

Ed

En el artículo , Ed Cryer
escribió:

Magician reports health as "Good" and "6.46TB written".

Sounds good to me. 6.5TB is nothing.

This is worth settling down with a cup of coffee for a read:

http://techreport.com/review/24841/i...ssd-endurance-
experiment

it's a torture test of several SSDs, in which they are subjected to
write loads far beyond what would be considered normal, until they fail.
The thing to watch out for is the failure mode - do they go read-only,
letting you retrieve your data, or do they crap out entirely?

It's in three parts, so get the coffee pot warmed up

Would you recommend running some independent analysis?

Give SSDLife a whirl:

http://ssd-life.com/

I got the Pro version from Giveaway of the Day a while back.

I wouldn't get too hung up on your SSD suddenly dying. It's no more or
no less likely than a HD suddenly turning its toes up on you. The
difference with HDs is that /usually/ you get some warning that it's
failing: funny noises, excessive retries, suddenly becoming slow, etc.
This gives you a chance to backup your data. In my experience SSDs
suddenly die and that's your lot.

You're doing the right thing keeping backups; obviously, you'd do this
whether the source was an HD or an SSD. One thing I will say is: backup
is only half the story. Restoring is the other half. So many people
have come to restore their backups to find that what was being "backed
up" wasn't what they expected, or that the restore fails because the
backup is corrupt. Do a couple of test restores to clean media before
trusting them.

Hope that helps, have fun

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

Mike Tomlinson wrote:
En el artÃ*culo , Ed Cryer
escribió:

Magician reports health as "Good" and "6.46TB written".

Sounds good to me. 6.5TB is nothing.

This is worth settling down with a cup of coffee for a read:

http://techreport.com/review/24841/i...ssd-endurance-
experiment

it's a torture test of several SSDs, in which they are subjected to
write loads far beyond what would be considered normal, until they fail.
The thing to watch out for is the failure mode - do they go read-only,
letting you retrieve your data, or do they crap out entirely?

It's in three parts, so get the coffee pot warmed up

Would you recommend running some independent analysis?

Give SSDLife a whirl:

http://ssd-life.com/

I got the Pro version from Giveaway of the Day a while back.

I wouldn't get too hung up on your SSD suddenly dying. It's no more or
no less likely than a HD suddenly turning its toes up on you. The
difference with HDs is that /usually/ you get some warning that it's
failing: funny noises, excessive retries, suddenly becoming slow, etc.
This gives you a chance to backup your data. In my experience SSDs
suddenly die and that's your lot.

You're doing the right thing keeping backups; obviously, you'd do this
whether the source was an HD or an SSD. One thing I will say is: backup
is only half the story. Restoring is the other half. So many people
have come to restore their backups to find that what was being "backed
up" wasn't what they expected, or that the restore fails because the
backup is corrupt. Do a couple of test restores to clean media before
trusting them.

Hope that helps, have fun


I've restored from backups many times. It's my special subject.

I gave SSDLife a spin (pardon the pun). I love the look of its results;
https://dl.dropboxusercontent.com/u/...35/SSDLife.JPG

Ed

En el artículo , Ed Cryer
escribió:

I gave SSDLife a spin (pardon the pun). I love the look of its results;
https://dl.dropboxusercontent.com/u/...35/SSDLife.JPG

I think it's safe to say you're doing OK

http://tinypic.com/view.php?pic=9a04qw&s=9

You'll see I don't turn mine off very much...

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

Per (PeteCresswell):
For better or for worse, I just bought a new System SSD based on
http://www.tomshardware.com/reviews/...mark,3269.html

And, based on this thread, I moved my swap file to a conventional drive.
--
Pete Cresswell

En el artículo ,
(PeteCresswell) escribió:

And, based on this thread, I moved my swap file to a conventional drive.

A good idea. Saves wear on the SSD.

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

On Mon, 30 Nov 2015 14:01:51 -0500, Paul wrote:

Ed Cryer wrote:
Mike Tomlinson wrote:
En el artículo , Ed Cryer
escribió:

. And a few weeks ago I did a
full scan with HDTune just to see how it was faring. Not a single dodgy
sector.

You were wasting your time, because you will never see a bad sector on
an SSD.


No time wasted at all. HD Tune works well with SSDs; whether it reports
them as blocks or sectors.

Ed

He is commenting on the sparing mechanism.

On a regular hard drive, a "spare" sector must
live in the neighborhood of a "defective" sector,
to take the place of the defective one.
(locality is probably required for some drives, not for others)

Because of that, a bad spot on the disk can rapidly
deplete the supply of usable spare sectors. Once
there are none left, a sector can have a "CRC error"
because the automatic sparing is no longer able to
repair it. That's when you start to see sectors
with the CRC error status. They can no longer
be repairs.
CRC error status should indicate that the data was lost,
not that it couldn't be corrected.

In the early 1980's various Digital Equipment Corporation SCSI
disks controllers (HSC70??) and disks (RA81?) automatically corrected
many errors but if the spot was bad enough the eventually the
data could not be corrected, and got an error message
the referenced the data that meant, approximately:
"the data in this block could not be written in the original
location, so the best guess was written here and flagged."

Note that:
1. There wasn't a utility to look for records that were
near failing, so you couldn't relocate them ahead of time.
2. Normal user programs couldn't find out that a record was
just flagged and relocated. (So you couldn't fix the error
while you had the data around in your program.)

I assume you could write data that was readable with only
correctable errors, and then, over time, the data would
decay so that when you tried to read it 6 months later you
would get the same error message, but the only cases that
I ran into were tracked down to the relocation actually
happening at the time of the write.

The SSD has no "geographical" limit to sparing. The
entire device relies on indirection. LBA 0 could be
at location 1234. LBA 1 could be at location 5678.
The layout is not guaranteed to be "linear" inside.
It's a jumble. Without the information in the
lookup table, you'd never be able to figure out
where anything went.

When a sector goes bad in that jumble, something
from the sparing section can be used. It doesn't
matter where that spare is located, it could
be at 2468, the seek time to *any* location
is the same.

So all that happens, is a lookup table is
updated with the "new" jumbled order. One
of the table entries has a new value. The
HDTune benchmark performance remains consistent.

When the entire global population of spares
is used up, then, the drive will issue some
kind of complaint. I don't know though,
exactly what SMART statistic would "blow"
if that happens :-)

*******

Some brands of SSDs shut down, when the
theoretical wear life is exceeded, so there
are some properties of SSDs that the owner
should research, such as the end-of-life
behavior. Intel branded devices have
particularly obnoxious behavior (I would
call it "Enterprise compatible" behavior,
because it assumes the user is showered
in backups). Most home users are not
really prepared for the end of life
process of their SSD, which is why the
warning is delivered. I would expect the
average user, to have no backup for their
SSD at all. And if one day, out of the
blue, it would neither read nor write,
they'd lose their data (no backup).
This isn't a hardware failure, it is a
policy decision.

Paul

On Tue, 1 Dec 2015 12:52:09 +0000, Mike Tomlinson wrote:

And, based on this thread, I moved my swap file to a conventional drive.

A good idea. Saves wear on the SSD.

Based on an article by Microsoft I left my Page File on the SSD. What's
the point in having an SSD if you're afraid to use it? I can't find the
M$ article at the moment, but if you search for 'microsoft ssd page
file' you'll find articles/postings that support page file on an SSD.

I quote:

quote

Dont be worry about wear on system drive ....U can rewrite
20-50GB(depends on the size of an SSD) on your drive every day (u dont
write all that much every day do u?) and it will be years before the
end. Isn't the idea of having SSD to to have super fast PC?

/quote

--
s|b

En el artículo , s|b
escribió:

Dont be worry about wear on system drive ....U can rewrite
20-50GB(depends on the size of an SSD) on your drive every day (u dont
write all that much every day do u?) and it will be years before the
end. Isn't the idea of having SSD to to have super fast PC?

With txt-spk English like that, would you really trust that person's
advice?

SSDs are for the most part, fairly small and contain the OS and
applications so those load quickly. The optimal solution is to have an
additional spinning-rust drive for user data and the pagefile.

If a Windows system is hitting the pagefile often, putting it on an SSD
is not the answer. Fitting more memory is.

Unless, of course, you only have the one drive (e.g. in a laptop), in
which case you don't have the option.

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

On Tue, 1 Dec 2015 18:48:18 +0000, Mike Tomlinson wrote:

With txt-spk English like that, would you really trust that person's
advice?

It's just an another example since I can't seem to find the article from
Microsoft. I'm using their product (Windows 7 x64 Home Edition SP1), so
I should trust (?) their judgment on this.

SSDs are for the most part, fairly small and contain the OS and
applications so those load quickly. The optimal solution is to have an
additional spinning-rust drive for user data and the pagefile.

I have, but only for data, not for Page File.

If a Windows system is hitting the pagefile often, putting it on an SSD
is not the answer. Fitting more memory is.

8 GiB RAM is more than enough for me.

Unless, of course, you only have the one drive (e.g. in a laptop), in
which case you don't have the option.

I have the option, but I'm following the advice Microsoft gives. I'm not
sure, but I think it was this article (although I think it was @
microsoft.com)

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

quote

*** Should the pagefile be placed on SSDs? ***

Yes. Most pagefile operations are small random reads or larger
sequential writes, both of which are types of operations that SSDs
handle well.

In looking at telemetry data from thousands of traces and focusing on
pagefile reads and writes, we find that

* Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
* Pagefile.sys read sizes are typically quite small, with 67% less
than or equal to 4 KB, and 88% less than 16 KB.
* Pagefile.sys writes are relatively large, with 62% greater than or
equal to 128 KB and 45% being exactly 1 MB in size.

In fact, given typical pagefile reference patterns and the favorable
performance characteristics SSDs have on those patterns, there are few
files better than the pagefile to place on an SSD.

/quote

Seems clear to me. If you don't like it, take it up to the author,
Steven Sinofsky. Let me know who wins, so I can leave it on the SSD or
move it to my SATA. ;-)

--
s|b

En el artículo , s|b
escribió:

http://blogs.msdn.com/b/e7/archive/2...r-solid-state-
drives-and.aspx

Thanks for digging that out, interesting.

Seems clear to me. If you don't like it, take it up to the author,
Steven Sinofsky.

Um, he was fired a couple years ago after the Win8 debacle... if you
consider Win8 is the pinnacle of his technological achievement, where
does that leave his advice on where to put the pagefile?

Let me know who wins, so I can leave it on the SSD or
move it to my SATA. ;-)

Nah, you're ok.

Fair dos, you're happy to follow the official advice and I won't. If it
breaks, I get to keep both bits

Cheers.

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

Per Mike Tomlinson:

If a Windows system is hitting the pagefile often, putting it on an SSD
is not the answer. Fitting more memory is.

I don't feel like I know nearly enough about page file use or how
Windows manages it to say anything.... but I did up my RAM to 16 gigs
because of certain graphics-intensive apps that I run... and I am hoping
that, since a TaskMan functional equivalent called Process Lasso usually
shows less than 60% of RAM in use that my PageFile activity is minimal.

Event tried turning it off for awhile.... went back to using it for
reasons I do not recall.... but the system did work...more-or-less...
--
Pete Cresswell

On Tue, 1 Dec 2015 20:20:01 +0000, Mike Tomlinson wrote:


http://blogs.msdn.com/b/e7/archive/2...r-solid-state-
drives-and.aspx

Thanks for digging that out, interesting.

I'm pretty sure that was the article that convinced me to leave the
pagefile on my SSD. I visited several sites to find out what's best and
it seemed there are as many sites that say it's ok than there are who
say it's not. Very confusing! So I just picked a side. :-)

Seems clear to me. If you don't like it, take it up to the author,
Steven Sinofsky.

Um, he was fired a couple years ago after the Win8 debacle... if you
consider Win8 is the pinnacle of his technological achievement, where
does that leave his advice on where to put the pagefile?

Well, I'm not completely ignorant, but I think he's got more knowledge
than me...

Let me know who wins, so I can leave it on the SSD or
move it to my SATA. ;-)

Nah, you're ok.

Fair dos, you're happy to follow the official advice and I won't. If it
breaks, I get to keep both bits

I bought my PC (and SSD; 120GB) on April 2012. It still works fine,
so... Every now and again I use Intel SSD Toolbox to do a quick or full
diagnostic scan. So far, so good! :-)

SSDLife Free says: 'Drive health is EXCELLENT!' and 'Estimated lifetime:
7 years 0 month 18 days'. Fingers crossed!

--
s|b