Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #2414 > unrolled thread

SSD drive reliability.

Back to article view | Back to comp.os.linux.hardware

Contents

  SSD drive reliability. wexfordpress <john@wexfordpress.com> - 2014-06-09 15:49 -0700
    Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-09 23:13 +0000
      Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-10 00:57 +0100
        Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-10 00:54 +0000
          Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-10 02:01 +0100
            Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-10 01:15 +0000
              Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-14 07:50 +0000
                Re: SSD drive reliability. Poutnik <poutnik@privacy.net> - 2014-06-14 10:19 +0200
                Re: SSD drive reliability. "Trevor Hemsley" <Trevor.Hemsley@mytrousers.ntlworld.com> - 2014-06-14 21:10 -0500
                  Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-15 08:48 +0000
                Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-16 10:41 +0200
                  Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-17 10:24 +0000
                    Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-17 12:24 +0100
                    Re: SSD drive reliability. Richard Kettlewell <rjk@greenend.org.uk> - 2014-06-17 12:44 +0100
                    Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-17 14:43 +0200
                    Re: SSD drive reliability. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2014-06-17 12:34 -0400
                      Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-18 10:06 +0200
                        Re: SSD drive reliability. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2014-06-19 16:29 -0400
                        Re: SSD drive reliability. Fredrik Jonson <fredrik@jonson.org> - 2014-08-13 09:15 +0000
                          Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-08-13 13:09 +0200
                            Re: SSD drive reliability. Richard Kettlewell <rjk@greenend.org.uk> - 2014-08-13 12:59 +0100
                              Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-08-13 15:52 +0200
        Re: SSD drive reliability. JEDIDIAH <jedi@nomad.mishnet> - 2014-06-09 19:45 -0500
          Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-10 08:51 +0200
    Re: SSD drive reliability. "Vince Coen" <VBCoen@gmail.com> - 2014-06-10 11:49 +0100

Page 1 of 2  [1] 2  Next page →

#2414 — SSD drive reliability.

Until recently the hybrid disk/SSD combo was the way to improve processing speed. But now the price of all SSD drives has dropped. How do they stack up for reliability?

John Culleton

[toc] | [next] | [standalone]

#2415

On Mon, 9 Jun 2014 15:49:58 -0700 (PDT), wexfordpress wrote:
 > Until recently the hybrid disk/SSD combo was the way to improve processing speed. 

That's one way to get the cost advantage of a HD with most
of the performance of a SSD, *but* without most of the other
advantages of an SSD: robustness, quietness, power usage
etc.

 > But now the price of all SSD drives has dropped. 
 > How do they stack up for reliability?

Google "SSD reliabilty" for several studies. Intel and Samsung
drive sare considered most reliable and SSDs in general are
considered to be much more reliable than HDs.

Bob T.

[toc] | [prev] | [next] | [standalone]

#2416

Bob Tennent <BobT@cs.queensu.ca> writes:

> SSDs in general are considered to be much more reliable than HDs.

When did this change?

Regardless of which type is more reliable, the failure modes are quite
different, which one needs to bear in mind if considering a switch.

-- 
Måns Rullgård
mans@mansr.com

[toc] | [prev] | [next] | [standalone]

#2417

On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
 >
 >> SSDs in general are considered to be much more reliable than HDs.
 >
 > When did this change?

  "From the data I've seen, client SSD annual failure rates
  under warranty tend to be around 1.5%, while HDDs are near
  5%," Chien said.

That quote is by Ryan Chien, an SSD and storage analyst with IHS's
Electronics & Media division.

http://www.computerworld.com/s/article/9242367

Bob T.

[toc] | [prev] | [next] | [standalone]

#2419

Bob Tennent <BobT@cs.queensu.ca> writes:

> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>  >
>  >> SSDs in general are considered to be much more reliable than HDs.
>  >
>  > When did this change?
>
>   "From the data I've seen, client SSD annual failure rates
>   under warranty tend to be around 1.5%, while HDDs are near
>   5%," Chien said.

How long is the warranty for each?  Does this statistic take into
account the vastly different capacities?

-- 
Måns Rullgård
mans@mansr.com

[toc] | [prev] | [next] | [standalone]

#2420

On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
 > Bob Tennent <BobT@cs.queensu.ca> writes:
 >
 >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
 >>  >
 >>  >> SSDs in general are considered to be much more reliable than HDs.
 >>  >
 >>  > When did this change?
 >>
 >>   "From the data I've seen, client SSD annual failure rates
 >>   under warranty tend to be around 1.5%, while HDDs are near
 >>   5%," Chien said.
 >
 > How long is the warranty for each?  Does this statistic take into
 > account the vastly different capacities?

The subject of SSD reliability is rather controversial. As I
suggested, Google "SSD reliabilty" for lots of discussion.

[toc] | [prev] | [next] | [standalone]

#2423

On Tue, 10 Jun 2014 01:15:14 +0000, Bob Tennent wrote:

> On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
>  > Bob Tennent <BobT@cs.queensu.ca> writes:
>  >
>  >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>  >>  >
>  >>  >> SSDs in general are considered to be much more reliable than
>  >>  >> HDs.
>  >>  >
>  >>  > When did this change?
>  >>
>  >>   "From the data I've seen, client SSD annual failure rates under
>  >>   warranty tend to be around 1.5%, while HDDs are near 5%," Chien
>  >>   said.
>  >
>  > How long is the warranty for each?  Does this statistic take into
>  > account the vastly different capacities?
> 
> The subject of SSD reliability is rather controversial. As I suggested,
> Google "SSD reliabilty" for lots of discussion.


What's the difference between an SSD and a flash usb stick?  I have tried 
repeatedly to use flash usb sticks as linux drives, using ext2 as the FS 
and mounted with the noatime option to avoid too many accesses.  After 
only a few mounts, these FS always end up corrupted.

The problem with flash is that "checking" them for integrity only 
decreases their lifetime.

I don't use flash anymore, for anything.

[toc] | [prev] | [next] | [standalone]

#2424

Dne 14.6.2014 9:50, Charles T. Smith napsal(a):
> On Tue, 10 Jun 2014 01:15:14 +0000, Bob Tennent wrote:
> 
>> On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
>>  > Bob Tennent <BobT@cs.queensu.ca> writes:
>>  >
>>  >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>>  >>  >
>>  >>  >> SSDs in general are considered to be much more reliable than
>>  >>  >> HDs.
>>  >>  >
>>  >>  > When did this change?
>>  >>
>>  >>   "From the data I've seen, client SSD annual failure rates under
>>  >>   warranty tend to be around 1.5%, while HDDs are near 5%," Chien
>>  >>   said.
>>  >
>>  > How long is the warranty for each?  Does this statistic take into
>>  > account the vastly different capacities?
>>
>> The subject of SSD reliability is rather controversial. As I suggested,
>> Google "SSD reliabilty" for lots of discussion.
> 
> 
> What's the difference between an SSD and a flash usb stick?  I have tried 
> repeatedly to use flash usb sticks as linux drives, using ext2 as the FS 
> and mounted with the noatime option to avoid too many accesses.  After 
> only a few mounts, these FS always end up corrupted.
> 
> The problem with flash is that "checking" them for integrity only 
> decreases their lifetime.
> 
> I don't use flash anymore, for anything.
> 
You may used them out of their purpose.

They are not designed for high speed and reliability as SSDs,
but rather for occasional use.

Neither have so many spare memory to fight with cell wearing.

It was often said NTFS should be applied on USB sticks,
FAT32 was more wearing friendly.

I know there is 2 approaches in NAND flash technology wear leveling.

One is built in wear levelling controller, dynamically remapping
sectors write requests for all cells share similar write counts.load.

The other are flash aware filesystems
https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems
https://en.wikipedia.org/wiki/Flash_file_system#Translation_layers

But I am not sure how much or where are used.

I have read somewhere Google was considering JFFS2 for Android at some
time, but later decided for classical Extn ( + probably WL controller)

More detailed study is adviced,
as I am definitely not an expert to flash nor Linux.

-- 
Poutnik

Wise man guards the words he says,
as they may speak about him more, than about the subject.

[toc] | [prev] | [next] | [standalone]

#2425

On Sat, 14 Jun 2014 07:50:22 UTC in comp.os.linux.hardware, "Charles T. Smith" 
<cts.private.yahoo@gmail.com> wrote:

> What's the difference between an SSD and a flash usb stick? 

USB sticks use the flash memory that wasn't good enough to go in SSDs.

-- 
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com

[toc] | [prev] | [next] | [standalone]

#2426

On Sat, 14 Jun 2014 21:10:06 -0500, Trevor Hemsley wrote:

> On Sat, 14 Jun 2014 07:50:22 UTC in comp.os.linux.hardware, "Charles T.
> Smith" <cts.private.yahoo@gmail.com> wrote:
> 
>> What's the difference between an SSD and a flash usb stick?
> 
> USB sticks use the flash memory that wasn't good enough to go in SSDs.


:)  That's reassuring!

[toc] | [prev] | [next] | [standalone]

#2427

On 14/06/14 09:50, Charles T. Smith wrote:
> On Tue, 10 Jun 2014 01:15:14 +0000, Bob Tennent wrote:
> 
>> On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
>>  > Bob Tennent <BobT@cs.queensu.ca> writes:
>>  >
>>  >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>>  >>  >
>>  >>  >> SSDs in general are considered to be much more reliable than
>>  >>  >> HDs.
>>  >>  >
>>  >>  > When did this change?
>>  >>
>>  >>   "From the data I've seen, client SSD annual failure rates under
>>  >>   warranty tend to be around 1.5%, while HDDs are near 5%," Chien
>>  >>   said.
>>  >
>>  > How long is the warranty for each?  Does this statistic take into
>>  > account the vastly different capacities?
>>
>> The subject of SSD reliability is rather controversial. As I suggested,
>> Google "SSD reliabilty" for lots of discussion.
> 
> 
> What's the difference between an SSD and a flash usb stick?  I have tried 
> repeatedly to use flash usb sticks as linux drives, using ext2 as the FS 
> and mounted with the noatime option to avoid too many accesses.  After 
> only a few mounts, these FS always end up corrupted.
> 
> The problem with flash is that "checking" them for integrity only 
> decreases their lifetime.
> 
> I don't use flash anymore, for anything.
> 

There is a world of difference between the average SSD and the average
flash stick (though less between the lowest of SSD's and the best of
flash sticks).

Flash sticks usually have minimal or no wear levelling, redundancy,
error checking, sector re-mapping, etc.  Instead of wear levelling, they
often have special flash for the first few MB's that supports many more
erase/write cycles - specifically to handle the extra pressure FAT
places on those sectors.  The rest of the flash is as cheap as possible,
as is the controller.

ext2 does not use a FAT - its high-use tables are in different areas of
the disk, thus you will wear out a USB flash stick faster with ext2 than
with FAT.

Flash sticks are also very prone to damage if you are not finished
writing before you remove them - always umount them (or at least "sync"
them) before unplugging.  It is not enough just to wait for the led (if
it has one) to go off.

[toc] | [prev] | [next] | [standalone]

#2428

On Mon, 16 Jun 2014 10:41:36 +0200, David Brown wrote:

> On 14/06/14 09:50, Charles T. Smith wrote:
>> On Tue, 10 Jun 2014 01:15:14 +0000, Bob Tennent wrote:
>> 
>>> On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
>>>  > Bob Tennent <BobT@cs.queensu.ca> writes:
>>>  >
>>>  >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>>>  >>  >
>>>  >>  >> SSDs in general are considered to be much more reliable than
>>>  >>  >> HDs.
>>>  >>  >
>>>  >>  > When did this change?
>>>  >>
>>>  >>   "From the data I've seen, client SSD annual failure rates under
>>>  >>   warranty tend to be around 1.5%, while HDDs are near 5%," Chien
>>>  >>   said.
>>>  >
>>>  > How long is the warranty for each?  Does this statistic take into
>>>  > account the vastly different capacities?
>>>
>>> The subject of SSD reliability is rather controversial. As I
>>> suggested, Google "SSD reliabilty" for lots of discussion.
>> 
>> 
>> What's the difference between an SSD and a flash usb stick?  I have
>> tried repeatedly to use flash usb sticks as linux drives, using ext2 as
>> the FS and mounted with the noatime option to avoid too many accesses. 
>> After only a few mounts, these FS always end up corrupted.
>> 
>> The problem with flash is that "checking" them for integrity only
>> decreases their lifetime.
>> 
>> I don't use flash anymore, for anything.
>> 
>> 
> There is a world of difference between the average SSD and the average
> flash stick (though less between the lowest of SSD's and the best of
> flash sticks).
> 
> Flash sticks usually have minimal or no wear levelling, redundancy,
> error checking, sector re-mapping, etc.  Instead of wear levelling, they
> often have special flash for the first few MB's that supports many more
> erase/write cycles - specifically to handle the extra pressure FAT
> places on those sectors.  The rest of the flash is as cheap as possible,
> as is the controller.
> 
> ext2 does not use a FAT - its high-use tables are in different areas of
> the disk, thus you will wear out a USB flash stick faster with ext2 than
> with FAT.
> 
> Flash sticks are also very prone to damage if you are not finished
> writing before you remove them - always umount them (or at least "sync"
> them) before unplugging.  It is not enough just to wait for the led (if
> it has one) to go off.


So, in conclusion - don't use an SSD if you're going to run linux.

As to wear-leveling ... that's presumably in the OS driver.  Maybe.  I 
wonder if any drivers report statistics.

I mean, the very concept of load leveling says everything that needs to 
be said.  What happens to those areas which get reduced usage?  It 
presumably means they've been worn - maybe they still work, but do you 
ever want to use them again?  Which access is going to be the one that 
tips them?

Is flash/SDD a fancy WORM drive?

[toc] | [prev] | [next] | [standalone]

#2429

"Charles T. Smith" <cts.private.yahoo@gmail.com> writes:

> On Mon, 16 Jun 2014 10:41:36 +0200, David Brown wrote:
>
>> On 14/06/14 09:50, Charles T. Smith wrote:
>>> On Tue, 10 Jun 2014 01:15:14 +0000, Bob Tennent wrote:
>>> 
>>>> On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
>>>>  > Bob Tennent <BobT@cs.queensu.ca> writes:
>>>>  >
>>>>  >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>>>>  >>  >
>>>>  >>  >> SSDs in general are considered to be much more reliable than
>>>>  >>  >> HDs.
>>>>  >>  >
>>>>  >>  > When did this change?
>>>>  >>
>>>>  >>   "From the data I've seen, client SSD annual failure rates under
>>>>  >>   warranty tend to be around 1.5%, while HDDs are near 5%," Chien
>>>>  >>   said.
>>>>  >
>>>>  > How long is the warranty for each?  Does this statistic take into
>>>>  > account the vastly different capacities?
>>>>
>>>> The subject of SSD reliability is rather controversial. As I
>>>> suggested, Google "SSD reliabilty" for lots of discussion.
>>> 
>>> 
>>> What's the difference between an SSD and a flash usb stick?  I have
>>> tried repeatedly to use flash usb sticks as linux drives, using ext2 as
>>> the FS and mounted with the noatime option to avoid too many accesses. 
>>> After only a few mounts, these FS always end up corrupted.
>>> 
>>> The problem with flash is that "checking" them for integrity only
>>> decreases their lifetime.
>>> 
>>> I don't use flash anymore, for anything.
>>> 
>>> 
>> There is a world of difference between the average SSD and the average
>> flash stick (though less between the lowest of SSD's and the best of
>> flash sticks).
>> 
>> Flash sticks usually have minimal or no wear levelling, redundancy,
>> error checking, sector re-mapping, etc.  Instead of wear levelling, they
>> often have special flash for the first few MB's that supports many more
>> erase/write cycles - specifically to handle the extra pressure FAT
>> places on those sectors.  The rest of the flash is as cheap as possible,
>> as is the controller.
>> 
>> ext2 does not use a FAT - its high-use tables are in different areas of
>> the disk, thus you will wear out a USB flash stick faster with ext2 than
>> with FAT.
>> 
>> Flash sticks are also very prone to damage if you are not finished
>> writing before you remove them - always umount them (or at least "sync"
>> them) before unplugging.  It is not enough just to wait for the led (if
>> it has one) to go off.
>
> So, in conclusion - don't use an SSD if you're going to run linux.

Wrong conclusion.  USB flash sticks are sometimes (allegedly) optimised
for FAT, but SATA-attached SSDs are a different story entirely.

> As to wear-leveling ... that's presumably in the OS driver.  Maybe.  I 
> wonder if any drivers report statistics.

Wear levelling is done entirely by the SSD controller.  The exact
implementations are closely guarded secrets of each manufacturer, but
broadly speaking, it works by continuously remapping logical sectors
(used in SATA commands) to different physical locations in the flash
memory.  Even sectors that are not explicitly written might be relocated
at times.  To aid the wear levelling process, SSDs support a "trim"
command which allows the OS to tell the drive when sectors no longer
hold useful data, e.g. after deleting a file.  Like HDDs, SSDs support
SMART for reporting various attributes related to the health of the
drive.

> I mean, the very concept of load leveling says everything that needs to 
> be said.  What happens to those areas which get reduced usage?  It 
> presumably means they've been worn - maybe they still work, but do you 
> ever want to use them again?  Which access is going to be the one that 
> tips them?
>
> Is flash/SDD a fancy WORM drive?

No.

-- 
Måns Rullgård
mans@mansr.com

[toc] | [prev] | [next] | [standalone]

#2430

"Charles T. Smith" <cts.private.yahoo@gmail.com> writes:
> As to wear-leveling ... that's presumably in the OS driver.  Maybe.  I 
> wonder if any drivers report statistics.

Garbage collection and wear levelling are functions of the device’s
controller chip, not the host OS.  The OS just sees a linear array of
blocks, just it does with a spinning disk (which is also likely to be
doing some rearrangement behind the scenes).

SMART can yield some useful stats with some SSDs.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#2431

On 17/06/14 12:24, Charles T. Smith wrote:
> On Mon, 16 Jun 2014 10:41:36 +0200, David Brown wrote:
> 
>> On 14/06/14 09:50, Charles T. Smith wrote:
>>> On Tue, 10 Jun 2014 01:15:14 +0000, Bob Tennent wrote:
>>>
>>>> On Tue, 10 Jun 2014 02:01:17 +0100, Måns Rullgård wrote:
>>>>  > Bob Tennent <BobT@cs.queensu.ca> writes:
>>>>  >
>>>>  >> On Tue, 10 Jun 2014 00:57:17 +0100, Måns Rullgård wrote:
>>>>  >>  >
>>>>  >>  >> SSDs in general are considered to be much more reliable than
>>>>  >>  >> HDs.
>>>>  >>  >
>>>>  >>  > When did this change?
>>>>  >>
>>>>  >>   "From the data I've seen, client SSD annual failure rates under
>>>>  >>   warranty tend to be around 1.5%, while HDDs are near 5%," Chien
>>>>  >>   said.
>>>>  >
>>>>  > How long is the warranty for each?  Does this statistic take into
>>>>  > account the vastly different capacities?
>>>>
>>>> The subject of SSD reliability is rather controversial. As I
>>>> suggested, Google "SSD reliabilty" for lots of discussion.
>>>
>>>
>>> What's the difference between an SSD and a flash usb stick?  I have
>>> tried repeatedly to use flash usb sticks as linux drives, using ext2 as
>>> the FS and mounted with the noatime option to avoid too many accesses. 
>>> After only a few mounts, these FS always end up corrupted.
>>>
>>> The problem with flash is that "checking" them for integrity only
>>> decreases their lifetime.
>>>
>>> I don't use flash anymore, for anything.
>>>
>>>
>> There is a world of difference between the average SSD and the average
>> flash stick (though less between the lowest of SSD's and the best of
>> flash sticks).
>>
>> Flash sticks usually have minimal or no wear levelling, redundancy,
>> error checking, sector re-mapping, etc.  Instead of wear levelling, they
>> often have special flash for the first few MB's that supports many more
>> erase/write cycles - specifically to handle the extra pressure FAT
>> places on those sectors.  The rest of the flash is as cheap as possible,
>> as is the controller.
>>
>> ext2 does not use a FAT - its high-use tables are in different areas of
>> the disk, thus you will wear out a USB flash stick faster with ext2 than
>> with FAT.
>>
>> Flash sticks are also very prone to damage if you are not finished
>> writing before you remove them - always umount them (or at least "sync"
>> them) before unplugging.  It is not enough just to wait for the led (if
>> it has one) to go off.
> 
> 
> So, in conclusion - don't use an SSD if you're going to run linux.

No - I have no idea how you could come up with that after reading my post.

The conclusion is that flash sticks have limited lifetimes no matter
what system, and will probably have problems faster with ext2 than with
FAT.  Flash sticks are usually very cheap, and you get the quality you
pay for.  But they are still perfectly usable with Linux (and Windows,
Macs, tablets, etc.), as long as you don't assume they will be reliable
for heavy usage over time.  There is also no requirement to use ext2 for
Linux - since flash sticks are often used to transfer data between
machines, it is very common to stick to FAT even if the main platform is
Linux.

And as I said, SSD's are a completely different thing.  A decent SSD is
going to be more reliable, and have a longer expected lifetime than a
harddisk.  It will also give better results with Linux than it would
with Windows (simply because the disk system and the filesystems are
better in Linux, and you can be more intelligent about trimming in Linux).

> 
> As to wear-leveling ... that's presumably in the OS driver.  Maybe.  I 
> wonder if any drivers report statistics.

No, it is not part of the OS driver - it is part of the firmware of the
device.  You will probably not be able to get much in the way of
statistics, as that will be internal to the drive.  But don't worry
about it - if you buy a good quality SSD (it does not need to be top of
the range) then you can usually write continuously at speeds of 30+ MB
every second for /years/ before wearing out the flash.

> 
> I mean, the very concept of load leveling says everything that needs to 
> be said.  What happens to those areas which get reduced usage?  It 
> presumably means they've been worn - maybe they still work, but do you 
> ever want to use them again?  Which access is going to be the one that 
> tips them?

Wear levelling is about spreading the erase/write loads across the flash
blocks, because flash blocks gradually deteriorate after between 1000 to
100000 erase/write cycles (depending on the type of flash).  The
deterioration is gradual, so the SSD firmware sees it is happening and
avoids re-writing a block that is becoming a problem long before it gets
unusable.  A good SSD will also move unchanging data around
occasionally, to make better use of blocks that are rarely written (this
is something that flash sticks, and old or cheapo SSDs usually do not
do).  So you can happily re-write the same logical block millions of
times, and the SSD firmware will spread it out across all blocks to give
an even wear.

> 
> Is flash/SDD a fancy WORM drive?
> 

No.

[toc] | [prev] | [next] | [standalone]

#2432

On Tue, 17 Jun 2014 06:24:13 -0400, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:

> So, in conclusion - don't use an SSD if you're going to run linux.

I've been using an ssd drive as my main drive for 3 years now. I'll
never go back to using a spinning disk as my main drive, due to the
speed difference.

I use opera for wab browsing, email, usenet, and rss feeds. I usually
have around 30 web tabs open, and have around 100,000 messages for it
to keep indexed. On a spinning disk, it takes 2 to 3 minutes to fully
open. On a ssd drive, it's under 15 seconds.

The one thing I learned the hard way, is that the os must enable the
trim function for filesystems on an ssd drive, or it will slow down
to the point it seems like an old floppy drive. I use the script
http://www.ody.ca/~dwhodgins/autofstrim
which I've copied to /etc/cron.daily

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#2433

On 17/06/14 18:34, David W. Hodgins wrote:
> On Tue, 17 Jun 2014 06:24:13 -0400, Charles T. Smith
> <cts.private.yahoo@gmail.com> wrote:
> 
>> So, in conclusion - don't use an SSD if you're going to run linux.
> 
> I've been using an ssd drive as my main drive for 3 years now. I'll
> never go back to using a spinning disk as my main drive, due to the
> speed difference.
> 
> I use opera for wab browsing, email, usenet, and rss feeds. I usually
> have around 30 web tabs open, and have around 100,000 messages for it
> to keep indexed. On a spinning disk, it takes 2 to 3 minutes to fully
> open. On a ssd drive, it's under 15 seconds.
> 
> The one thing I learned the hard way, is that the os must enable the
> trim function for filesystems on an ssd drive, or it will slow down
> to the point it seems like an old floppy drive. I use the script
> http://www.ody.ca/~dwhodgins/autofstrim
> which I've copied to /etc/cron.daily
> 

That is the right way to handle trimming - but your description is a bit
inaccurate.

There are three ways to handle trim on an SSD (on Linux - other OS's are
more limited).  You can ignore it, you can enable a trim mount option
(for ext4 and possibly other systems), or you can use fstrim for offline
trimming.

Ignoring trim is actually a perfectly good solution for modern SSDs of a
reasonable size.  They have good garbage collection, and
overprovisioning means that there are always free blocks on hand.  The
slowdown and extra wear in comparison to a trimmed SSD is very minor or
negligible for many loads.  Older and smaller SSDs get more benefit from
trim.

Online trim using a mount option means that when a filesystem deletes a
file, it immediately sends a trim on the freed blocks.  This makes them
available to the SSD without delay - but because the complete morons who
specified SATA TRIM made it non-queueable and synchronous (instead of
copying the SCSI TRIM commands), a TRIM is a very slow operation that
blocks everything else on the disk.  Thus online TRIM makes many
operations, especially deletes and other metadata changes, significantly
slower.  It is seldom a good solution.

Offline trim using "fstrim" lets you get the benefits of trimming, by
sending TRIM commands for all parts of the partition that are not used
by the filesystem.  It can take a bit of time to run, depending on the
state of the filesystem, as is best done off-peak.  I believe most
distros now install suitable cron jobs by default, or you can have your
own own.


So usually I would recommend "fstrim" or simply ignoring trim (as long
as your disk is reasonably new).  But the phrase "enable the trim
function for the filesystem" implies to me a trim mount, and that is
something you normally want to avoid.


mvh.,

David


> Regards, Dave Hodgins
> 

[toc] | [prev] | [next] | [standalone]

#2435

On Wed, 18 Jun 2014 04:06:42 -0400, David Brown <david.brown@hesbynett.no> wrote:


> So usually I would recommend "fstrim" or simply ignoring trim (as long
> as your disk is reasonably new).  But the phrase "enable the trim
> function for the filesystem" implies to me a trim mount, and that is
> something you normally want to avoid.

My three year old 256 GB OCZ-AGILITY4 ssd drive worked well for about 8
months, then slowed to a crawl. I'm on the Mageia qa team, so was using
it to test installs from new iso images, so pretty heavy on writes to
the drive.

At first I was using the discard option in /etc/fstab for all of the
ext4 file systems, which, while it did speed things up, was noticeably
slower then without the discard option.

Switching to using the fstrim command, for all ssd mounted file systems
(except swap, with can only be trimmed using the discard option, as it
doesn't have a mount point), returned the drive's speed to "like new",
and it's been working very well since then. I've since moved the swap
to an actual spinning disk, but with 16GB of ram, it's rarely used
anyway.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#2520

In <lnrhaj$giu$1@dont-email.me> David Brown wrote:
 
>  Online trim using a mount option means that when a filesystem deletes a
>  file, it immediately sends a trim on the freed blocks.  This makes them
>  available to the SSD without delay - but because the complete morons who
>  specified SATA TRIM made it non-queueable and synchronous (instead of
>  copying the SCSI TRIM commands), a TRIM is a very slow operation that
>  blocks everything else on the disk.

Sorry for reviving an old thread but the TRIM command is queuable nowdays.  A
queued trim command was introduced in Sata 3.1 and is supported in the linux
kernel as of version 3.12. So the old advice to avoid online trim because it
is non-queued should not be relevant any more.

http://en.wikipedia.org/wiki/Trim_(computing)

Note that there may be other reasons to not use online trim such as disk
encryption and buggy ssd firmware.

-- 
Fredrik Jonson

[toc] | [prev] | [next] | [standalone]

#2521

On 13/08/14 11:15, Fredrik Jonson wrote:
> In <lnrhaj$giu$1@dont-email.me> David Brown wrote:
>  
>>  Online trim using a mount option means that when a filesystem deletes a
>>  file, it immediately sends a trim on the freed blocks.  This makes them
>>  available to the SSD without delay - but because the complete morons who
>>  specified SATA TRIM made it non-queueable and synchronous (instead of
>>  copying the SCSI TRIM commands), a TRIM is a very slow operation that
>>  blocks everything else on the disk.
> 
> Sorry for reviving an old thread but the TRIM command is queuable nowdays.  A
> queued trim command was introduced in Sata 3.1 and is supported in the linux
> kernel as of version 3.12. So the old advice to avoid online trim because it
> is non-queued should not be relevant any more.
> 
> http://en.wikipedia.org/wiki/Trim_(computing)
> 
> Note that there may be other reasons to not use online trim such as disk
> encryption and buggy ssd firmware.
> 

That's useful information.  Of course, we have to wait for Sata 3.1
motherboards/controller boards, and Sata 3.1 drives to take advantage of
it.  But otherwise it's good to see that horrendously stupid rush-job
Sata TRIM is finally half-fixed.

The other fix (which may be in the Sata 3.1 specs - I haven't bought
them to look) would be to specify that a trimmed block reads as all
zeros.  At the moment, some drives return zeros, some return the old
data, some return whatever happened to be in the drive's cache, and some
might return data that is logically in another part of the disk.  This
all has two problems - one is data security, and the other is that it is
a wasted opportunity for disk formatting and for raid.  If returning
zeros for read of a trimmed block were mandated, initialising and
synchronising a new raid array would be done with a couple of trim commands.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.hardware

csiph-web