Question Crucial MX500 500GB SATA SSD - - - Remaining Life decreasing fast despite only a few bytes being written to it ?

[Lucretia19]

The Remaining Life (RL) of my Crucial MX500 ssd has been decreasing rapidly, even though the pc doesn't write much to it. Below is the log I began keeping after I noticed RL reached 95% after about 6 months of use.

Assuming RL truly depends on bytes written, the decrease in RL is accelerating and something is very wrong. The latest decrease in RL, from 94% to 93%, occurred after writing only 138 GB in 20 days.

(Note 1: After RL reached 95%, I took some steps to reduce "unnecessary" writes to the ssd by moving some frequently written files to a hard drive, for example the Firefox profile folder. That's why only 528 GB have been written to the ssd since Dec 23rd, even though the pc is set to Never Sleep and is always powered on. Note 2: After the pc and ssd were about 2 months old, around September, I changed the pc's power profile so it would Never Sleep. Note 3: The ssd still has a lot of free space; only 111 GB of its 500 GB capacity is occupied. Note 4: Three different software utilities agree on the numbers: Crucial's Storage Executive, HWiNFO64, and CrystalDiskInfo. Note 5: Storage Executive also shows that Total Bytes Written isn't much greater than Total Host Writes, implying write amplification hasn't been a significant factor.)

My understanding is that Remaining Life is supposed to depend on bytes written, but it looks more like the drive reports a value that depends mainly on its powered-on hours. Can someone explain what's happening? Am I misinterpreting the meaning of Remaining Life? Isn't it essentially a synonym for endurance?

�

Crucial MX500 500GB SSD in desktop pc since summer 2019​
Date​	Remaining Life​	Total Host Writes (GB)​	Host Writes (GB) Since Previous Drop​
12/23/2019​	95%​	5,782​	​
01/15/2020​	94%​	6,172​	390​
02/04/2020​	93%​	6,310​	138​

 

[worstalentscout]

You could set CrystalDiskInfo to alert you when Remaining Life drops below 85%.

Emptying the Recycle Bin allows the ssd to write to those blocks after it erases them. But the need to erase blocks is caused by writing to the ssd, and the amount of writing doesn't depend on whether or how often you empty the RB. (Unless you run out of free space because you haven't emptied the RB) If the blocks occupied by files in the RB aren't available for erasing & writing because the RB hasn't been emptied, the ssd will erase other free blocks in order to write somewhere. (Unless it has run out of free space, in which case you need to free some space by emptying the RB, at least partially.)

The mystery I mentioned is why your ABEC count is LOWER than what I expect for 85% Remaining Life. So I'm unsure what you're referring to where you ask about "the higher number of erases."

ok...........will update when life drops to 84%..........

 

[worstalentscout]

ok...........will update when life drops to 84%..........

so the Life Remaining just dropped to 84% after 208 Average Block Erases and 11,137 GB written............let's see how many Erases and GB written before it drops to 83%....

 

[Lucretia19]

so the Life Remaining just dropped to 84% after 208 Average Block Erases and 11,137 GB written............let's see how many Erases and GB written before it drops to 83%....

100 - 84 = 16.
208 / 16 is exactly 13.
This strongly suggests your 250GB MX500 uses one percent of Remaining Life for each 13 increments of ABEC, so I predict your ABEC will reach 221 when Remaining Life reaches 83%.

What's the version of the firmware in your 250GB MX500?

You might want to set CrystalDiskInfo to alert you when Remaining Life falls below 84%.

 

[worstalentscout]

100 - 84 = 16.
208 / 16 is exactly 13.
This strongly suggests your 250GB MX500 uses one percent of Remaining Life for each 13 increments of ABEC, so I predict your ABEC will reach 221 when Remaining Life reaches 83%.

What's the version of the firmware in your 250GB MX500?

You might want to set CrystalDiskInfo to alert you when Remaining Life falls below 84%.

firmware is M3CR043..........couldn't update to M3CR046............

the Crystaldiskinfo is always active...........i enjoy looking at it multiple times a day.......LOL

 

[Lucretia19]

firmware is M3CR043..........couldn't update to M3CR046............

the Crystaldiskinfo is always active...........i enjoy looking at it multiple times a day.......LOL

Our 250GB MX500s have different versions of the firmware; mine has an older version: M3CR020. (I bought it for my laptop computer during the spring of 2018.) I assume this accounts for our two 250GB drives' different values of "ABEC per Percent of Life." Your 13 and my 15.

Just speculating: Perhaps Crucial learned that 1500 average erases before failure of the 250GB MX500 was too optimistic, and corrected it to 1300 in later firmware.

I wonder if mine would switch to 13 if I update its firmware. Perhaps its initial choice of 15 is permanent. Perhaps the update would be smart enough to change to 13 and also correct Remaining Life downward.

Aren't there other things you enjoy more than looking at CrystalDiskInfo, that you lack time to do? De gustibus non est disputandum, I guess.

You might want to install HWInfo, which can display a lot of info about the hardware in your computer. It's VERY customizable. You could use it to display the ssd Remaining Life in the Windows tray. It can alert when hardware values are outside a desired range. It can log values to a file. On my pc I set it to display in the Windows Tray the ssd's average write rate (aggregated since Windows restart) -- currently 0.108 MB/second -- and the cpu temperature. On my laptop I set it to alert when the battery charge is less than 40% or more than 80%, to help me maximize the battery's lifespan. (Few devices can be configured to automatically stop charging their battery below 100%, so they require manual disconnection of the charger.)

 

[worstalentscout]

Our 250GB MX500s have different versions of the firmware; mine has an older version: M3CR020. (I bought it for my laptop computer during the spring of 2018.) I assume this accounts for our two 250GB drives' different values of "ABEC per Percent of Life." Your 13 and my 15.

Just speculating: Perhaps Crucial learned that 1500 average erases before failure of the 250GB MX500 was too optimistic, and corrected it to 1300 in later firmware.

I wonder if mine would switch to 13 if I update its firmware. Perhaps its initial choice of 15 is permanent. Perhaps the update would be smart enough to change to 13 and also correct Remaining Life downward.

Aren't there other things you enjoy more than looking at CrystalDiskInfo, that you lack time to do? De gustibus non est disputandum, I guess.

You might want to install HWInfo, which can display a lot of info about the hardware in your computer. It's VERY customizable. You could use it to display the ssd Remaining Life in the Windows tray. It can alert when hardware values are outside a desired range. It can log values to a file. On my pc I set it to display in the Windows Tray the ssd's average write rate (aggregated since Windows restart) -- currently 0.108 MB/second -- and the cpu temperature. On my laptop I set it to alert when the battery charge is less than 40% or more than 80%, to help me maximize the battery's lifespan. (Few devices can be configured to automatically stop charging their battery below 100%, so they require manual disconnection of the charger.)

ok, many thanks

 

[worstalentscout]

so the Life Remaining just dropped to 84% after 208 Average Block Erases and 11,137 GB written............let's see how many Erases and GB written before it drops to 83%....

life remaining just dropped to 83%.............

221 erases............11,758GB written.........

 

[Lucretia19]

That's further confirmation of "13 ABEC increments per percent of life used." 221 / (100-83) = 13.

To extrapolate your ssd's total endurance:
11,758GB x 100 / (100-83) = 69,165GB, which is roughly 69 TB.
That's much less than Crucial's 100 TB endurance spec for the 250GB MX500.

To estimate whether the endurance shortfall is growing worse by extrapolating from the most recent 1% decrease from 84% to 83%:
Your pc wrote 11,758GB - 11,137GB = 621GB during the drop from 84% to 83%. Multiplying by 100, that extrapolates to about 62 TB total endurance. Since 62 TB < 69 TB, the problem may be growing worse.

 

[worstalentscout]

That's further confirmation of "13 ABEC increments per percent of life used." 221 / (100-83) = 13.

To extrapolate your ssd's total endurance:
11,758GB x 100 / (100-83) = 69,165GB, which is roughly 69 TB.
That's much less than Crucial's 100 TB endurance spec for the 250GB MX500.

To estimate whether the endurance shortfall is growing worse by extrapolating from the most recent 1% decrease from 84% to 83%:
Your pc wrote 11,758GB - 11,137GB = 621GB during the drop from 84% to 83%. Multiplying by 100, that extrapolates to about 62 TB total endurance. Since 62 TB < 69 TB, the problem may be growing worse.

just hope it can withstand 6000 erases like in the experiment...........if it can do that, then nothing to worry about..........

 

[Lucretia19]

just hope it can withstand 6000 erases like in the experiment...........if it can do that, then nothing to worry about..........

Setting aside the question of whether the 6000 erases experimental result is relevant to real world usage that has much lower write rates and erase rates than in the experiment... There's some evidence (discussed at the end of my previous reply) that your ssd's problem is growing worse. (Accelerating.) Assuming it's growing worse, we don't yet know how much it will grow.

On the other hand, it might have just been a random fluctuation that the 62 TB estimated endurance extrapolated from the most recent 1% decrease of Remaining Life is less than the 69 TB estimated endurance extrapolated from the entire 17% of Life Used.

The amounts written by your pc during the next few 1% drops of RL can provide more data points to help see whether the problem is growing worse.

Your 250GB ssd isn't (yet) behaving as badly as my 500GB ssd was before the ssd selftests regime. Here's the corresponding data for my 500GB MX500, showing its problem grew worse (before the selftests) and got to be about 5 times worse than your 621GB written from 84% RL to 83% RL:

Date​	Remaining Life %​	Total Host Writes (GB)​	Host Writes (GB) during most recent decrement of Remaining Life​
07/28/2019​	100​	0​	​
08/31/2019​	99​	1,772​	1,772​
​	98​	​	​
​	97​	​	​
​	96​	​	​
12/23/2019​	95​	5,782​	​
01/15/2020​	94​	6,172​	390​
02/04/2020​	93​	6,310​	138​
03/13/2020​	92​	6,647​	337​
10/19/2020​	91​	8,178​	1,531​
09/16/2021​	90​	9,395​	1,217​
05/20/2022​	89​	10,532​	1,137​
11/12/2022​	88​	12,082​	1,550​
04/11/2023​	87​	13,535​	1,453​

I began the selftests regime on 2/22/2020. The fourth column clearly shows the problem appeared to be accelerating before that: The pc wrote only 138 GB during the drop from 94% RL to 93% RL. (You can see the huge improvement during the 3+ years under the selftests regime.)

The 92% row, which is the data for the drop from 93% RL to 92% RL, covers both a few weeks (2/04/2020 to 2/22/2020) before the selftests and a few weeks (2/22/2020 to 3/13/2020) with the selftests. So the data in the 92% row is for a mixture of the ssd's behaviors. To separate the mix and see more clearly how the ssd behaved during the final few weeks before the selftests began on 2/22/2020, here's data logged on increments of Average Block Erase Count rather than on decrements of Remaining Life. You can see that the problem was very bad during the final few weeks before the selftests began:

Date​	Average Block Erase Count (ABEC)​	Total Host Writes (GB)​	Host Writes (GB) during most recent increment of ABEC​
02/09/2020​	109​	6,342​	32​
02/12/2020​	110​	6,365​	23​
02/14/2020​	111​	6,390​	25​
02/15/2020​	112​	6,393​	3​
02/16/2020​	113​	6,404​	11​
02/18/2020​	114​	6,416​	12​
02/19/2020​	115​	6,422​	6​
02/20/2020​	116​	6,429​	7​
02/22/2020​	117​	6,442​	13​
02/28/2020​	118​	6,495​	53​
03/05/2020​	119​	6,548​	53​
03/13/2020​	120​	6,647​	99​
03/25/2020​	121​	6,749​	102​
04/10/2020​	122​	6,855​	106​
04/21/2020​	123​	6,984​	129​

 

[worstalentscout]

so did you return your 500GB MX500 ?............or since it's ''working'' so they rejected your return request ?

 

[Lucretia19]

so did you return your 500GB MX500 ?............or since it's ''working'' so they rejected your return request ?

I discussed that in early posts here. To summarize: In February 2020 Crucial offered to replace the ssd, but only if I first shipped it to them. I haven't done that because (1) I didn't want my pc to be inoperative for a week or two, (2) I didn't have a strong incentive to replace it after I found the selftests regime mitigates the bug and appeared to have no undesirable side effects except consuming about one watt of power, and (3) in 2020 it seemed likely that a replacement drive would have the same bug and might be a refurbished drive in worse condition.

In the past, other drive manufacturers were willing to ship replacement drives BEFORE the customer returned the defective drive. I hope that policy is still typical for most drive manufacturers. It gets the replacement into the customer's hands sooner, and if the defective drive is still readable the customer can clone the data to the replacement before returning the defective drive. (And if the defective drive is still erasable, the customer can and should erase it using a secure erase algorithm before shipping it back.)

 

[worstalentscout]

In the past, other drive manufacturers were willing to ship replacement drives BEFORE the customer returned the defective drive. I hope that policy is still typical for most drive manufacturers. It gets the replacement into the customer's hands sooner, and if the defective drive is still readable the customer can clone the data to the replacement before returning the defective drive. (And if the defective drive is still erasable, the customer can and should erase it using a secure erase algorithm before shipping it back.)

lucky thing i never had a SSD fail so far..........in my country, i will have to bring the SSD to the Crucial distributor's service center...........not sure if i'll get a replacement SSD on the spot or not...........but for some brands, i heard people had to wait for weeks for a replacement drive !

 

[maximum-cache]

Using Hard Disk Sentinel I notice that every so often I'm getting the errors:

Current Pending Sector Count 0 -> 1

then exactly five minutes later:

Current Pending Sector Count 1 -> 0

and it seems to be related to the issues discussed in this thread.

The above errors don't occur every day, sometimes a week or two can elapse while at other times they may occur on successive days, but rarely more than once a day.

The SSD (a 2TB Crucial MX500) is approaching three years old. Hard Disk Sentinel reports that the Health is 'Excellent' at 89%

The firmware is M3CR032 and I see on the Crucial site that it can be upgraded to M3CR033 (I've not done that yet but I assume that I should?).

Is there anything in particular that I should be doing to alleviate the excessive writes problem highlighted in this thread?

 

[Lucretia19]

Using Hard Disk Sentinel I notice that every so often I'm getting the errors: Current Pending Sector Count 0 -> 1
then exactly five minutes later:
Current Pending Sector Count 1 -> 0
and it seems to be related to the issues discussed in this thread.

The above errors don't occur every day, sometimes a week or two can elapse while at other times they may occur on successive days, but rarely more than once a day.

Your ssd is experiencing that event rarely enough that you probably don't need to mitigate the problem, unless the frequency of the events increases.

Also, note that that event might be a sign of a different kind of problem than the "excessive writes" problem that this thread is about. Your ssd may have one or more bad memory cells that the ssd is having trouble reading. If your ssd has that problem, SMART attributes such as "Raw Read Error Rate" (attribute 01), "Reallocated NAND Blocks" (attribute 05), Reported Uncorrectable Errors" (attribute B8), and "Reallocation Event Count" (attribute C4) might provide clues, because they relate to bad memory cells.

If your ssd does have the "excessive writes" problem, there are other SMART attributes that provide more direct information about it. In particular, "Host Program Page Count" (attribute F7) and "Background Program Page Count" (attribute F8). The ssd's Overall Write Amplification Factor (OWAF) is 1 + F8/F7 and the smaller the better. I recommend you periodically log those two attributes, say once per day of once per week, for awhile, so that you can use the amount that F7 & F8 increased during each logging period, ΔF7 & ΔF8, to calculate the Write Amplification Factor during each period of time: 1 + ΔF8/ΔF7. If this value has a small average, say 4 or less, then your ssd isn't writing so excessively that it's worth mitigating.

Other attriibutes worth logging are "Average Block Erase Count" (ABEC, attribute AD) and perhaps "Percent Lifetime Used" (also known as Remaining Life, attribute CA). If you detect a significant increase in the rate at which ABEC increments, and if that's not due to increased writing to the ssd by your computer (ΔF7 or ΔF6), then the increased rate would be a sign of growing excessive writes (ΔF8 larger than it ought to be).

If you determine that your ssd isn't writing excessively, you could reduce the logging rate to each time ABEC increments. You may be able to set HD Sentinel to alert you each time ABEC increments. (On my computer, I run software that automatically logs several SMART attributes every two hours and daily, into two separate log files.)

At nearly three years of use, 89% Remaining Life by itself isn't a sign of a problem. If that rate continues then the ssd would last about 25 more years, nothing to worry about. Did you log the date when Remaining Life reached 90%, so that you could detect whether the drop from 90% to 89% was faster than previous decrements?

If your ssd firmware is really M3CR032 and not M3CR023, then your ssd might not be prone to the excessive writes problem. Crucial revised the hardware to use a different controller chip that seems to have fixed the bug, according to reports from other people. (My own ssd is 4 years old and has M3CR023 and the older controller chip.)

One other thing to consider is how long your ssd is allowed to run without powering it off. I haven't rigorously analyzed my log data but I've seen strong signs that excessive writing increases if the ssd doesn't get power cycled for a couple of weeks. So I shut down the computer once a month when Windows does a monthly update requiring a restart. And I put the computer to sleep (which powers off the ssd) for a few seconds, typically about two weeks after each monthly Windows update. My logging software alerts me each day that 1 + ΔF8/ΔF7 > 4 for the previous 24 hours, and I sleep the computer for a few seconds after that happens two or three times.

Good luck!

The SSD (a 2TB Crucial MX500) is approaching three years old. Hard Disk Sentinel reports that the Health is 'Excellent' at 89%

The firmware is M3CR032 and I see on the Crucial site that it can be upgraded to M3CR033 (I've not done that yet but I assume that I should?).

Is there anything in particular that I should be doing to alleviate the excessive writes problem highlighted in this thread?

 

[maximum-cache]

Thanks very much for the very detailed and helpful response.

On looking at the SMART data I see that most of the entries read:

OK (Always Passing)

although there are two which just read OK, and those are:

Reallocated Sectors Count

Percentage of the Rated Lifetime Use

In the Threshold column these read, respectively, 10 and 1

Yes, the firmware on the main drive is definitely M3CR032 while the other SSD (see below) is M3CR045

So I upgrade the M3CR032 to M3CR033 ?

I should have added that I have another SSD of the exact same type in the PC (but with later firmware) - I use that as a backup device so it's only really accessed when I backup to it. The temperature of the main drive (which I initially wrote about) runs about 7 degrees celcius higher than the mostly unused backup SSD, even when it's barely being used. For example, right now the main SSDD is reading 33 and the backup is 26. Yesterday the main drive went up to 45 when Malwarebytes was doing a scan.

Good point about powering off the PC, I tend to leave it on and only reboot it once every few weeks but rarely power it down, even briefly.

 

[Lucretia19]

Reallocated Sectors Count
Percentage of the Rated Lifetime Use
In the Threshold column these read, respectively, 10 and 1
...
So I upgrade the M3CR032 to M3CR033 ?
...
For example, right now the main SSDD is reading 33 and the backup is 26. Yesterday the main drive went up to 45 when Malwarebytes was doing a scan.

I don't know the meaning of the Threshold column. It doesn't appear to be significant. My ssd shows Threshold=10 in "Reallocated NAND Blocks" (attribute (05) and Threshold=1 in "Percent Lifetime Used" (attribute CA), like your ssd does. My hunch is that the Threshold column is just constants set by the drive's manufacturer. The Current Column and the Raw Values column are the columns to pay attention to. For most attributes, the Raw Values column.

Are you planning to periodically log the Raw Values of "Host Program Page count" (attribute F7) and "Background Program Page count" (attribute F8)? As I described in my previous reply, the ratio of the changes of these two attributes over time would let you know if your ssd has started to experience the excessive writes problem.

I think HD Sentinel automatically logs some attributes related to bad or weak sectors, and stores their most recent 50 values. You might want to view its log to see if any of those attributes have been recently increasing. For more info, see: HD Sentinel Help - Log

I can't provide informed advice about whether to update the firmware to 033. I don't know what's different about it. Perhaps Crucial's website offers info about whether to update, such as a list of fixes & new features. People often advise: if it ain't broke don't fix it.

The temperatures you report seem very healthy... even the 45C while the ssd is very active. The ssds are rated to be able to handle much higher temperatures, around 70C, I think. (My ssd stays at around 45C due to the constant read activity of the selftests I run. There's a health tradeoff, because constant temperature is better for hardware but higher temperature is worse for hardware.) Regarding the 7C difference between your main ssd and your backup ssd, my guesses are either greater air flow from your case fan(s) across the backup ssd, or the backup ssd experiences a deep sleep mode due to its prolonged inactivity.

 

[maximum-cache]

Where is the Raw Values column under Hard Disk Sentinel?

Also, where are Host Program Page count & Background Program Page count - I can't see them under SMART ?

Many thanks again for the great help and advice.

 

[Lucretia19]

Where is the Raw Values column under Hard Disk Sentinel?

Also, where are Host Program Page count & Background Program Page count - I can't see them under SMART ?

Many thanks again for the great help and advice.

The attribute & column labels that I've been mentioning are the labels displayed by CrystalDiskInfo. I guess HD Sentinel uses different labels. Judging from their website, I think the HD Sentinel "Data" column corresponds to the CrystalDiskInfo "Raw Values" column. If HD Sentinel is displaying the Data column in hexadecimal (base 16), it might be easier for you to interpret the data if you change the setting to display it in decimal (base 10).

The SMART attribute number should be the same in both apps. But it could be displayed in either hexadecimal or decimal, depending on how you have HD Sentinel configured. Host Program Page Count is attribute F7 (in hexadecimal), which is attribute 247 in decimal. Background Program Page Count is F8 (in hexadecimal), which is 248 in decimal. These two attributes are probably at the bottom of the list of SMART data, so you might need to scroll down to see them.

 

[maximum-cache]

Thanks very much, and apologies for the late reply.

 

[iDAX]

I face the same issue with my MX500 1TB. I bought it in late 2019 and then started to use it as the main system drive, also for cache and temp files.
The Health % was going down very fast and every day I can see some #197 alerts in HDS.

For reference(From CDI 9.1.1):
Firmware: M3CR023
Health Status: 59%
Total Host Writes: 64,517GB
Power On Hours: 7458 hours

 

[Lucretia19]

I face the same issue with my MX500 1TB. I bought it in late 2019 and then started to use it as the main system drive, also for cache and temp files.
The Health % was going down very fast and every day I can see some #197 alerts in HDS.

For reference (from CDI 9.1.1):
Firmware: M3CR023
Health Status: 59%
Total Host Writes: 64,517GB
Power On Hours: 7458 hours

It looks like you're saying your ssd's Remaining Life is now decreasing much faster than it used to and that you're getting Current Pending Sector Count (attribute 197) alerts that you didn't used to get. How long ago did the Remaining Life (also called Health Status) begin to decrease very fast? How long ago did you begin to have the alerts for Current Pending Sector Count?

To mitigate the problem, you might want to use the software that I posted here in 2020 (spring or early summer). While the software runs, it orchestrates the ssd to run nearly continuous selftests: 19.5 minutes of every 20 minutes. (The selftests don't slow the ssd's read/write performance, because selftesting is a lower priority operation than host reading and host writing.) The reason why the ssd selftests mitigate the problem is that selftesting is a higher priority operation than the ssd controller's buggy excess background writing, so running the selftests nearly nonstop causes the lower priority buggy routine to get much less runtime: only 30 seconds of every 20 minutes. To use the software, you'd want to set your computer to run it every time the computer starts or restarts. (Assuming you're running Windows, you could set that using Windows Task Scheduler.) If memory serves, my message that includes the .BAT software describes the parameters in the .BAT file that you might need to edit to match your hardware configuration.

You also might want to begin periodically -- daily or weekly or monthly -- logging some relevant SMART attributes. In particular, attributes 247 and 248 can be used together to calculate the ssd's Write Amplification Factor. The ratio of their changes during each logging period -- the increase of 248 divided by the increase of 247 -- would let you know the write amplification behavior during each logging period. If the ratio is high, then the ssd has the excess background writing problem. Periodically logging the attributes so you can see the rates of changes would let you know how the ssd is performing now, which is more relevant than its total performance over the last 4 years.

Note: Your 7458 "Power On Hours" is probably very misleading. The ssd weirdly doesn't count as "On" the time it spends in its low-power mode, and it often goes into low-power mode. (The selftests would keep the ssd busy and prevent it from entering low-power mode, which would make the Power On Hours more accurate.) Try estimating how many hours your computer has been powered on since the ssd was installed in 2019, and compare it to 7458.

 

[worstalentscout]

life remaining just dropped to 83%.............

221 erases............11,758GB written.........

life remaining = just dropped to 82%...........

234 erases.............12449 GB written............

write amplification.............1.73...........

 

[Lucretia19]

life remaining just dropped to 83%.
221 erases............11,758GB written.
life remaining = just dropped to 82%.
234 erases.............12449 GB written.
write amplification.............1.73.

If 1.73 is the write amplification over the ssd's several years of operation, then it doesn't tell us anything about the ssd's recent behavior. If the ssd has recently developed a problem it would mean write amplification was okay for years, and it doesn't tell us much about the recent behavior if you average the old good behavior with the recent behavior. How about showing us how you calculated the write amplification?

The 1% drop of Remaining Life while total bytes written by the pc increased from 11,758 GB to 12,449 GB is more revealing of the ssd's recent behavior. 12449 minus 11758 is 691 GB. If the ssd continues at that rate for the remaining 82%, that would mean the pc can write an additional 82 x 691 GB = 57 TB. Add to 57 TB the 12449 GB already written, and the ssd's extrapolated total endurance comes to approximately 70 TB, which is far below its official endurance spec and suggests it has the excessive FTL Controller writes bug.

To check whether the problem is accelerating, we can compare with the data you reported earlier: 84% Remaining Life at 11,137 GB written. 11758 minus 11137 is 621 GB. Thus the pc wrote 621 GB while the ssd Remaining Life decreased from 84% to 83%. So we can infer that the ssd's write amplification was a little worse during the drop from 84% to 83% than during the more recent drop from 83% to 82%. However, the difference between 621 GB and 691 GB isn't huge, so it might be just a random fluctuation.

Given the data you've provided, it appears the ssd has the excessive writes bug but there's no sign yet that it's accelerating.

 

[worstalentscout]

If 1.73 is the write amplification over the ssd's several years of operation, then it doesn't tell us anything about the ssd's recent behavior. If the ssd has recently developed a problem it would mean write amplification was okay for years, and it doesn't tell us much about the recent behavior if you average the old good behavior with the recent behavior. How about showing us how you calculated the write amplification?

The 1% drop of Remaining Life while total bytes written by the pc increased from 11,758 GB to 12,449 GB is more revealing of the ssd's recent behavior. 12449 minus 11758 is 691 GB. If the ssd continues at that rate for the remaining 82%, that would mean the pc can write an additional 82 x 691 GB = 57 TB. Add to 57 TB the 12449 GB already written, and the ssd's extrapolated total endurance comes to approximately 70 TB, which is far below its official endurance spec and suggests it has the excessive FTL Controller writes bug.

To check whether the problem is accelerating, we can compare with the data you reported earlier: 84% Remaining Life at 11,137 GB written. 11758 minus 11137 is 621 GB. Thus the pc wrote 621 GB while the ssd Remaining Life decreased from 84% to 83%. So we can infer that the ssd's write amplification was a little worse during the drop from 84% to 83% than during the more recent drop from 83% to 82%. However, the difference between 621 GB and 691 GB isn't huge, so it might be just a random fluctuation.

Given the data you've provided, it appears the ssd has the excessive writes bug but there's no sign yet that it's accelerating.

no way for me to update the firmware though.........tried many times and now even Crucial Storage Executive won't run !!

i'm still hoping this SSD can reach 6000 erase cycles ..........then i got nothing to worry about.......