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​

 

[Maxxify]

Check the SMART values 247 (F7) and 248 (F8) as these will let you calculate write amplification. Check pgs. 25-26 here for more information. You can also check to see if any spare blocks have been used, etc., but I would not be concerned in general.

 

[Lucretia19]

@Maxxify, thanks for replying so quickly. I've used the formula for Write Amplification Factor on page 26 of the Micron document to calculate the Write Amplification:

Date​	Total Host Writes (GB)​	S.M.A.R.T. F7​	S.M.A.R.T. F8​	WAF = (F7+F8)/F7​	Total Amplified Writes (GB)​
02/06/2020​	6,323​	219,805,860​	1,229,734,020​	6.59​	41,698​

Note: The size of a NAND page is about 30 KBytes according to a 9-page 2019 academic paper I found by googling 'nand page size crucial mx500' ("Why and How to Increase SSD Performance Transparency" at http://www.cs.technion.ac.il/~dan/papers/frvrs-hotos-2019.pdf ). That's similar to the ratio of Total Host Writes to SMART F7 above, which is about 29 KB.

Is the 6.59 WAF unusually large for an ssd that's mostly empty and hasn't had a lot of deletes?

Can you explain the acceleration of the decrease of Remaining Life versus bytes written?

Now that I know the WAF, I assume the Total Bytes Written that was displayed by Storage Executive is really the same as Total Host Writes. It must just use a different unit that makes it seem a little larger, like the way a MByte is more than 1 million bytes. It's sad that Storage Executive doesn't display Total Writes Including Amplification.

I assume write amplification can be improved by write caching. The Windows 10 write cache policy has been its default setting: Enabled, with buffer-flushing Not turned off. I presume Momentum Cache could do a better job than Windows cache to reduce write amplification, but I've been unable to "activate" Momentum Cache and none of the suggestions from tech support were able to identify the reason why not. (In their most recent email, after a couple weeks of silence, they asked if my pc has an uninterruptible power supply -- it does -- and asked me to run the two self-tests in Storage Executive -- both succeeded. Waiting to see if they have any other ideas, and if they will ever respond to my concern about the accelerating decrease of Remaining Life.)

Why would you not be "concerned in general?" If it's because you can afford to replace your hardware frequently, that's not as general as can be. I don't have much income so I want my hardware to endure for MANY years. And I don't want to be victimized by read errors in a few years. (For the same reason, I set the BIOS to underclock cpu & dram and lowered max cpu power consumption & dram voltage.)

Thanks again for your help!

Check the SMART values 247 (F7) and 248 (F8) as these will let you calculate write amplification. Check pgs. 25-26 here for more information. You can also check to see if any spare blocks have been used, etc., but I would not be concerned in general.

 

[Lucretia19]

In the pdf paper that I linked in my post yesterday is a chart that shows the Write Amplification Factor for the Crucial MX500 ssd, measured using five kinds of write workloads. The measured WAF ranges from about 0.3 to 1.2. Those values are MUCH less than the 6.59 that my MX500 has been experiencing. It sure seems like my MX500 is not behaving properly. What could explain its horrible writing inefficiency? (Note: The chart is in the upperleft corner of page 4 of the paper.)

 

[Lucretia19]

By googling I found a Micron paper about Write Amplification Factor that also discusses how to calculate the "recent" WAF, by keeping track of the increases of SMART F7 & F8 over time and using the increases in the formula. (You can find the paper by googling its title: "tnfd23_m500_smart_attributes_calc_waf.pdf".)

The formula for the Recent WAF is:
1 + ΔF8/ΔF7
where ΔF7 and ΔF8 are the increases in F7 and F8 over the recent period of time.

I applied that formula over the most recent day -- roughly the most recent 24 hours -- and the WAF during the most recent day has been 56.79 !!! That seems outrageously large. See the three rightmost columns in the following table (you may need to scroll to the right to see them):

Date​	Total Host Writes (GB)​	S.M.A.R.T. F7​	S.M.A.R.T. F8​	WAF = 1 + F8/F7​	Total Amplified Writes (GB)​	ΔF7​	ΔF8​	Recent WAF = 1 + ΔF8/ΔF7​
02/06/2020​	6,323​	219,805,860​	1,229,734,020​	6.59​	41,698​	​	​	​
02/07/2020​	6,329​	220,037,004​	1,242,628,588​	6.65​	42,071​	231,144​	12,894,568​	56.79​

What could cause the WAF to be so high??

 

[Lucretia19]

I have a theory to test, about why the WAF has been so high. The Momentum Cache in Storage Executive has been "unable to activate" since I installed Storage Executive many weeks ago. (Crucial/Micron's tech support has been unable to find out why it won't activate, and I don't know if they've given up trying.) My theory is that the Momentum Cache cache driver has been preventing Windows 10's write cache from operating, causing all writes to execute immediately, rather than allowing multiple writes to be aggregated together into large sequential writes.

To try to test the theory, today I set Storage Executive to "disable" Momentum Cache, which seems to have resulted in the cache driver being deleted, according to a message that displayed before it restarted the pc. During the days and weeks to come, I will occasionally record the SMART F7 and F8 values and calculate the recent WAF. (See my previous post about how to measure "recent WAF.")

If it turns out that the "unactivated" Momentum Cache driver has been responsible for the outrageously large WAF, this is an unacceptable bug.

 

[Maxxify]

I'm aware of that paper. It does have some deficiencies but I'll cover the details quickly. The page size of Micron's flash is 16KB raw, but there's always spare/ECC data among other things. Also, I usually put consumer WAF in the 1.5-2.0 range. While sub-1.0 is certainly possible with compression, Micron's dynamic write acceleration (dynamic SLC) can only have an additive factor from 0 to 2, it's not going to bring WAF below 1.0. However anything over about 2.0 would be considered high in my opinion. Technically WAF is 1 + write differential (248/247) because again, no compression implies 1.0 at best.

By not worrying about it I meant: these drives can sustain a metric ton of writes, in the PB range. It's likely to fail elsewhere. I've covered this exact topic with other SSD owners before. That being said...Momentum Cache is no different than Samsung's RAPID Mode which is pure hokum. All it does is use system RAM for caching. Your OS already does that, you're just adding overhead. The technique is outdated. You never want to run it except in very niche cases. I'll have to see if I can find the person who had the same issue as you on Reddit as I concluded it was a sleep/hibernate bug, I don't think he mentioned using MC...

 

[Lucretia19]

Unless Micron's terminology is misleading, the equation "NAND_Page_Size = Total_Host_Writes / F7" implies page size is approximately 29 KBytes. (6,329 GB / 220,037,004 is approximately 28.8 KBytes).

I've continued to log S.M.A.R.T. numbers: Total Host Writes, F7 and F8. During the most recent 24 hours, WAF has been approximately 39.6 (and during the most recent 48 hours has been approximately 47.7). During most of the most recent 24 hours, the Momentum Cache driver has been deleted, which might partially explain the decrease in WAF from 56.8 a day ago to 39.6 today. But 39.6 still seems outrageously large.

I've also begun logging the Average Block-Erase Count (ABEC), which appears to be closely related to the ssd drive's remaining life. Today, Current ABEC is 93 and Raw ABEC is 108. Given the formula in Micron's S.M.A.R.T. Attributes document, Current ABEC appears to be the same as Remaining Lifetime (93%) because Current ABEC is normalized to the rated life of a block:
Current ABEC = 100 x (1 - AverageEraseCount/RatedEraseCount).
Raw ABEC is the average erase count of all super blocks, where a super block consists of the same-numbered blocks in all planes. I don't know how many planes the ssd has, but 108 seems excessively large for a 500 GB ssd that's had 6,329 GB host bytes written to it.

I'm not confident that the ssd will fail due to some other cause before it fails due to excessive write amplification. What other cause is likely to make it fail before write amplification kills it? Its average temperature has been below 35C and its peak temperature rarely exceeds 45C. (It's mounted in the case right behind a constant speed intake fan, and its 2.5" SATA form factor has more area than the M.2 form factor for dissipating heat.)

I don't see how the cause of the high write amplification could be a sleep/hibernate bug. Many months ago, about two months after the pc and ssd were new last summer, I set the pc to never sleep. Specifically, Windows' active power plan has "never sleep," "never hibernate," and "turn off the hard disk after zero minutes." (My understanding is that "zero minutes" means never.) Perhaps you're referring to the ssd's DevSleep feature?

 

[Maxxify]

The actual page size is 16KB most likely but it differs depending on the flash - their 32L/384Gb uses a 24KB page size, for example. The real size is larger by 2208B for ECC/spare area in that case.

Yes, lifespan may be determined by P/E which is directly related to the block-erase count. Not sure how Micron tracks it but usually it's straight up average erases per block which translates directly to P/E, given in hex. So 108 = 264 P/E, (264)/(0.07) = 3771 but it's probably set towards 3500 P/E. I have a NS200 (same hardware as the MX500) and this is SMART 167 (A7) but may be 168 (A8) on the MX500. Definitely a very high WAF in that case (~20).

Controllers brick themselves all the time, or other components go bad/short. Power loss/crashing is also a primary method of corrupting the drive due to the volatile nature of its DRAM and just mapping in general. Temperature is not the primary issue per se. The issue with sleep/hibernate is that it will write RAM to the disk and this can have high WAF if it's done repeatedly or incorrectly and many devices have issues with sleep. Yes, obviously, having sleep disabled makes this unlikely or impossible, but it's often related to power settings (in theory). Other issues could be Windows detecting it as a HDD (unlikely) for optimization, improper paging, things of that nature. Quite frankly it's not a common problem that I've seen and I don't know why certain drives get it. The MX500 does rely on Micron's dynamic write acceleration (basically, dynamic SLC) which can have an additive factor for WAF but it's never going to be above 2. So you are having writes committed to TLC and then rewritten multiple times (SLC would defer writes).

 

[fzabkar]

How would WAF be impacted by a full disk in the absence of TRIM? Could the absence of TRIM explain the OP's problem?

It might be interesting to see if the incremental WAF increases if TRIM were to be disabled.

 

[Maxxify]

How would WAF be impacted by a full disk in the absence of TRIM? Could the absence of TRIM explain the OP's problem?

It might be interesting to see if the incremental WAF increases if TRIM were to be disabled.

Well, I did mention to check to be sure Windows recognized the drive as a SSD for optimization. Windows basically does retrim during optimization if it is (TRIM/UNMAP for all unused sectors). You can of course verify if TRIM is enabled, but you are correct that TRIM helps reduce write amplification as it helps with garbage collection and the reduction of unnecessary page writes. These activities are done when idle (in the background) so the drive being maintained in constant use would be quite a problem, but that could also be related to power states. So it would exacerbate the issue.

 

[Lucretia19]

TRIM is enabled and ReTrim is scheduled once per week.

The 108 value that I mentioned above for RAW Average Block-Erase Count is in base 10, not base 16.

"Disabling" (deleting) the "inactive" Momentum Cache driver, which I did on Friday, hasn't helped. Below is the data for the last three days, which shows -- see the column in red, you may need to scroll to the right -- that WAF has been 68.87 during the most recent 24-ish hour period:

Date​	Total Host Writes (GB)​	S.M.A.R.T. F7​	S.M.A.R.T. F8​	WAF = 1 + F8/F7​	Total Amplified Writes (GB)​	ΔF7 (1 row)​	ΔF8 (1 row)​	Recent WAF = 1 + ΔF8/ΔF7​	ΔF7 (2 rows)​	ΔF8 (2 rows)​	Recent WAF (2 rows) = 1 + ΔF8/ΔF7​
02/06/2020​	6,323​	219,805,860​	1,229,734,020​	6.59​	41,698​	​	​	​	​	​	​
02/07/2020​	6,329​	220,037,004​	1,242,628,588​	6.65​	42,071​	231,144​	12,894,568​	56.79​	​	​	​
02/08/2020​	6,334​	220,297,938​	1,252,694,764​	6.69​	42,351​	260,934​	10,066,176​	39.58​	492,078​	22,960,744​	47.66​
02/09/2020​	6,342​	220,530,596​	1,268,485,627​	6.75​	42,821​	232,658​	15,790,863​	68.87​	493,592​	25,857,039​	53.39​

An email yesterday from Micron tech support offers no useful advice: "For the momentum cache issue, as you have already followed all the troubleshooting, I would suggest you try once uninstalling the Crucial Storage executive and then install it again. The issue might be with the power management on your system or with the Storage executive. For the % drop, it might be due to the continuous read and write from the SSD. However, for both the issues if persists, you can discard using Crucial storage executive, and use any other 3rd party SSD ‘monitoring and controlling’ software for momentum cache."

Their advice isn't useful because:
(1) I'd already tried uninstalling/reinstalling Storage Executive many weeks ago (the first time they suggested it).
(2) It seems absurd to suggest the rapid % drop in Remaining Life might be due to "continuous read and write" since my ssd has much less written to it than most people write to their ssds. HWiNFO shows Average Write Rate has been less than 0.1 MBytes/sec for many weeks (only 19 GB total during the last three days, according to the increase of Total Host Writes from 6,323 GB on Feb 6 to 6,342 GB on Feb 9.) and occasionally shows the Current Write Rate is 0. The Average Read Rate has been about 0.22 MBytes/sec and Current Read Rate is occasionally 0.
(3) They failed to specify which third party SSD 'monitoring and controlling' software might be compatible with the MX500.

For reference, the motherboard is a MSI X470 Gaming Plus, the cpu is a Ryzen 3 3200G, and the system has 16GB (2 x 8GB) of Corsair Vengeance 3200 dram (underclocked at 2400 so it will run at 1.2V). No graphics card is installed since the cpu is an apu.

Perhaps a third party driver is causing the problem? VMware Player has been installed since last summer, and although I rarely run a vm anymore, VMware Player has self-installed some updates. Perhaps a buggy virtual disk driver could interfere with the ssd even when Player isn't running a vm?

Could software that monitors S.M.A.R.T. data interfere with the ssd? A moment ago I exited HWiNFO and CrystalDiskInfo, which normally run 24 hours per day. In a day or two I can check the recent WAF to see if it's affected by not running them.

Is it possible that the ssd firmware goes bananas when the host writing is much less than typical? It might be a use case that Crucial/Micron never tested. It was about two months ago, when the Remaining Life reached 95%, that I took steps to significantly reduce host writing (moving the Firefox profile to a hard drive, setting a simlink so the CyberPower UPS logs to hard drive instead of ssd, disabling Comodo's antivirus scanning within compressed archives, etc) yet the rate of decrease in Remaining Life has accelerated since then. Over the approximately 7 months that the ssd has been in use, its WAF has averaged 6.75 (the Feb 9 value in the table above) which is an order of magnitude less than the WAF values of recent days. It could be a coincidence, though, since Windows, MSI drivers and other software have received updates that might be responsible.

Any suggestions about what I should try?

Is it reasonable to request warranty replacement of the ssd?

 

[Maxxify]

108 would then be would then be 108 P/E, which makes more sense as my NS200's health % is based on 1500 P/E: (100/7)(108) = 1543. So that seems right at least. Although this flash is good for far more than that, at least 3000 and upwards of 5-10K depending on other factors. So yes, a lot of use for six months, but it would still survive more than a decade.

I don't have any further advice at this time. For monitoring I use Hard Disk Sentinel.

 

[Mr.Spock]

it has a 5yr wty and is rated for 180TBW - so no need to panic just yet.
even dropping 1% per month you're talking about an 8yr duty cycle.

You can always RMA later if RL becomes really alarming.

moving frequently files to the HDD may not help if your TEMP: is still the SSD - it's still a pass-thru.

Also leaving the computer on vs suspending shouldn't matter as that's done to memory. Hibernate would be different. Leaving it on enables more background writes/updates than suspend in fact.

I would check how much pagefile you're using and what restore space is set to, you may be rewriting more than you need to.

I'd also check the Crucial firmware and make sure you're not using a bad one, also check if AHCI settings are correct (assume this is so if TRIM is working)

to put it in perspective you've written 6.2TB / 180 = ~3.5% (vs 5% is relatively insignificant).

VM's do use a lot of SSD space so that might be throwing off whatever algorithm the SSD is using for RL. But the value is close to what you'd expect statistically

TRIM is enabled and ReTrim is scheduled once per week.

The 108 value that I mentioned above for RAW Average Block-Erase Count is in base 10, not base 16.

"Disabling" (deleting) the "inactive" Momentum Cache driver, which I did on Friday, hasn't helped. Below is the data for the last three days, which shows -- see the column in red, you may need to scroll to the right -- that WAF has been 68.87 during the most recent 24-ish hour period:

Date​	Total Host Writes (GB)​	S.M.A.R.T. F7​	S.M.A.R.T. F8​	WAF = 1 + F8/F7​	Total Amplified Writes (GB)​	ΔF7 (1 row)​	ΔF8 (1 row)​	Recent WAF = 1 + ΔF8/ΔF7​	ΔF7 (2 rows)​	ΔF8 (2 rows)​	Recent WAF (2 rows) = 1 + ΔF8/ΔF7​
02/06/2020​	6,323​	219,805,860​	1,229,734,020​	6.59​	41,698​	​	​	​	​	​	​
02/07/2020​	6,329​	220,037,004​	1,242,628,588​	6.65​	42,071​	231,144​	12,894,568​	56.79​	​	​	​
02/08/2020​	6,334​	220,297,938​	1,252,694,764​	6.69​	42,351​	260,934​	10,066,176​	39.58​	492,078​	22,960,744​	47.66​
02/09/2020​	6,342​	220,530,596​	1,268,485,627​	6.75​	42,821​	232,658​	15,790,863​	68.87​	493,592​	25,857,039​	53.39​

An email yesterday from Micron tech support offers no useful advice: "For the momentum cache issue, as you have already followed all the troubleshooting, I would suggest you try once uninstalling the Crucial Storage executive and then install it again. The issue might be with the power management on your system or with the Storage executive. For the % drop, it might be due to the continuous read and write from the SSD. However, for both the issues if persists, you can discard using Crucial storage executive, and use any other 3rd party SSD ‘monitoring and controlling’ software for momentum cache."

Their advice isn't useful because:
(1) I'd already tried uninstalling/reinstalling Storage Executive many weeks ago (the first time they suggested it).
(2) It seems absurd to suggest the rapid % drop in Remaining Life might be due to "continuous read and write" since my ssd has much less written to it than most people write to their ssds. HWiNFO shows Average Write Rate has been less than 0.1 MBytes/sec for many weeks (only 19 GB total during the last three days, according to the increase of Total Host Writes from 6,323 GB on Feb 6 to 6,342 GB on Feb 9.) and occasionally shows the Current Write Rate is 0. The Average Read Rate has been about 0.22 MBytes/sec and Current Read Rate is occasionally 0.
(3) They failed to specify which third party SSD 'monitoring and controlling' software might be compatible with the MX500.

For reference, the motherboard is a MSI X470 Gaming Plus, the cpu is a Ryzen 3 3200G, and the system has 16GB (2 x 8GB) of Corsair Vengeance 3200 dram (underclocked at 2400 so it will run at 1.2V). No graphics card is installed since the cpu is an apu.

Perhaps a third party driver is causing the problem? VMware Player has been installed since last summer, and although I rarely run a vm anymore, VMware Player has self-installed some updates. Perhaps a buggy virtual disk driver could interfere with the ssd even when Player isn't running a vm?

Could software that monitors S.M.A.R.T. data interfere with the ssd? A moment ago I exited HWiNFO and CrystalDiskInfo, which normally run 24 hours per day. In a day or two I can check the recent WAF to see if it's affected by not running them.

Is it possible that the ssd firmware goes bananas when the host writing is much less than typical? It might be a use case that Crucial/Micron never tested. It was about two months ago, when the Remaining Life reached 95%, that I took steps to significantly reduce host writing (moving the Firefox profile to a hard drive, setting a simlink so the CyberPower UPS logs to hard drive instead of ssd, disabling Comodo's antivirus scanning within compressed archives, etc) yet the rate of decrease in Remaining Life has accelerated since then. Over the approximately 7 months that the ssd has been in use, its WAF has averaged 6.75 (the Feb 9 value in the table above) which is an order of magnitude less than the WAF values of recent days. It could be a coincidence, though, since Windows, MSI drivers and other software have received updates that might be responsible.

Any suggestions about what I should try?

Is it reasonable to request warranty replacement of the ssd?

 

[Lucretia19]

@Maxxify, the ~6 average WAF over the drive's first ~5 months seems irrelevant. The main issue is that WAF is now around 60, an order of magnitude higher. Because WAF is now so huge, it's not comforting that the ssd could last over a decade if its WAF were to average "only" 6.75 over that decade. At the current tiny Average Host Write Rate (less than 0.1 MBytes/second) and huge WAF, the drive might barely exceed its 5 year warranty, but I wouldn't want to be forced to maintain the current tiny write rate; that would be an unreasonable restriction.

@Mr.Spock, I don't see how writing caused by the pagefile, the vm or Temp files could explain the huge WAF. Also, the pagefile, vm and Temp files are already accounted for because those writes are included in the Average Host Writes, which is tiny. Furthermore, I moved the pagefile to a hard drive many months ago. I almost never run the vm... not once during the last month. Comodo periodically wrote a lot of temporary files to the ssd when its weekly Full Scan was set to virus-scan compressed archives, which is why I decided to disable scanning of compressed archives after the ssd Remaining Life reached 95%. (An alternative would be to learn where Comodo writes those temporary files and create a symlink from there to a folder on a hard drive.)

According to Storage Executive, the ssd's firmware is up to date (and it's the same version as when the drive was new, M3CR023). I don't know how to check whether the firmware is a "bad one" but I presume it's not bad if it's up to date, and Micron tech support didn't say it was bad.

According to the BIOS, AHCI is enabled.

The Average Block Erase Count incremented to 109 while I wrote this post. <sigh>

 

[Mr.Spock]

109 / 3000 = ~3.63% which sort of matches your TBW count.

so 95-97% RL is about right, again you're looking at 6+ yrs at the current rate

 

[Lucretia19]

@Mr.Spock: I think you're confirming there's a big problem, because 6+ years is unreasonably short given the tiny 0.1 MBytes/second Average Host Write Rate.

Not sure what you mean by "95-97% RL is about right." RL is 93% and was 95% about 6 weeks ago.

Here's an additional mystery I just noticed: The S.M.A.R.T. "Power On Hours" is 968. That's only about 40 days, even though the ssd has been in service since last summer and the pc has been on and set to Never Sleep for nearly all of the last 5 months. Here's an excerpt about Power On Hours from Micron's S.M.A.R.T. Attributes document:

This value gives the raw number of hours that the
drive has been under power (online) over its lifetime.
This attribute shall increment for each hour in
the following link power state:
• SATA PHYRDY (Link Active)
This attribute may not increment for each hour in
the following link power states:
• SATA Partial
• SATA Slumber
• SATA Device Sleep

Is it really possible that the ssd has spent most of its time in the Partial or Slumber or Device Sleep state, given that the pc has been on and Never Sleeping and the power plan setting of "Turn off hard disk after" is 0 minutes?

In case the ssd went wild due to the pc being left on for many weeks without a shutdown, I briefly shut it down a little while ago. Before the shutdown, I set HWiNFO and CrystalDiskInfo so they won't start with Windows, and I won't run them for a few days, in case their monitoring somehow interferes with the ssd. I'll keep tracking WAF each day to see if any of those steps helped.

At some point I may increase the write rate to see if that has an effect on WAF. I could move the Firefox profile back to the ssd, for instance.

 

[USAFRet]

Why don't you contact Crucial, and see what they say.
Especially in light of the suspiciously low Power On hours.

 

[fzabkar]

I don't understand why the formula for WAF is not …

WAF = F8 /F7

… rather than …

WAF = (F8 + F7) / F7 = 1 + F8/F7

The latter WAF value can never be less than 1, even with compression.

 

[Mr.Spock]

Assume you mean power plan setting of Turn off hard disk after = "Never"?
yes that would mean the SATA controller is periodically being slept as opposed to the disk.

Again 6yrs minimum is the indicator right now given TBW and P/E cycles. You have 4 yrs to RMA as well if you feel it is defective - but the stats don't seem alarming right now.

 

[Lucretia19]

@USAFRet: I contacted Crucial tech support weeks ago right after Remaining Life reached 94% and have done everything they requested, and they appear to have given up trying to help; see their most recent email quoted in an earlier post. However, I didn't ask them about the mysteriously low Power On Hours, so I will ask them about that when I find time.
@fzabkar: I don't see a setting in Storage Executive to enable compression. Assuming Micron ssds don't offer an internal compression feature, it follows that "F7+F8" is the total pages written to the ssd flash memory. Then "1 + F8/F7" is the factor that, when multiplied by Host Bytes Written (F7) and divided by the page size, gives "F7+F8."
@Mr.Spock: Yes, after the user chooses Never for "turn off hard disk after," Windows displays "0 minutes" when you look at it again later. I'm surprised you think I shouldn't be alarmed that the host pc writing 138 GB consumed 1% of the ssd life (from 94% to 93%). As I've repeatedly said, the decrease in RL has been accelerating. It's misleading to pay too much attention to the first 5 months of its life.
Here's the "Remaining Life versus Host Bytes Written" data that I've logged:
99% after 1,772 GB (August 31)
[didn't log the next three 1% decreases]
95% after 5,782 GB (Dec 23)
94% after 6,172 GB (Jan 15)
93% after 6,310 GB (Feb 4)
As you can see, the decrease in RL as a function of Host Bytes Written has been accelerating:
RL decreased 1% after the host wrote 1772GB,
decreased 4% more after an additional 4010GB (avg 1002GB per %),
decreased 1% more after an additional 390GB,
and decreased 1% more after an additional 138GB.
If it continues to accelerate like that, the ssd will die long before the 5 year warranty expires. But even if it doesn't accelerate, unless WAF gets much better the ssd will last much less than it ought to, given how little is written to it.

 

[fzabkar]

The way I see it, the total bytes written from the host are written to a RAM buffer before they are committed to NAND. So F7 is the total written to RAM, while F8 is the total written to NAND. Otherwise how do you account for reports of write amplification numbers less than 1?

https://en.wikipedia.org/wiki/Write_amplification

WA is typically measured by the ratio of Writes committed to the flash memory to the Writes coming from the host system. Without compression, WA cannot drop below one. Using compression, SandForce has claimed to achieve a write amplification of 0.5, with best-case values as low as 0.14 in the SF-2281 controller.

This begs the question, what is the WAF for DRAM-less SSDs? They would temporarily commit the data to NAND in SLC mode, and then transfer to it to TLC NAND at a later date. This would suggest that WAF would always be greater than 1 for this architecture.

 

[fzabkar]

Could the OP's drive be a fake?

Crucial's BX500 is DRAM-less and uses the SM2258XT controller.

Crucial's MX500 uses an SM2258 controller.

AIUI, when data are written to "SLC cache", the TLC NAND gives up 3 bits for every single bit received from the host. These data are subsequently recommitted to TLC NAND. Therefore, ISTM that at least 4 bits are written for each bit received, ie the WA is at least 4 (or 1 + 4, if you use the other formula).

But this only applies to DRAM-less cases, or am I misunderstanding how SLC caching works?

 

[Lucretia19]

@fzabkar: Micron agrees that WAF is the total NAND writes divided by the total host writes (but they seem to have a blindspot regarding the possibility of internal compression). Here's an excerpt from Micron's WAF document:

WAF is the ratio of total writes to the NAND divided by the total writes intended by the host computer. An ideal WAF would be exactly 1.0.

Note however that attribute F8 (248 in base 10) is NOT the total NAND writes. Here's another excerpt from Micron's WAF document:

Attribute 247 is the total number of NAND page program operations initiated by the host computer. Attribute 248 is the number of NAND page program operations initiated by the SSD's Flash Translation Layer (FTL) and are in addition to the operations programmed by the host.

Thus the total NAND writes (in units of NAND pages) on a Micron ssd is F7+F8.

The Wikipedia article about SMART attributes doesn't list F7 or F8 as being standard among all drive manufacturers. ( https://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes )

Here's a quote from earlier in that Wiki article:

From a legal perspective, the term "S.M.A.R.T." refers only to a signaling method between internal disk drive electromechanical sensors and the host computer. Because of this the specifications of S.M.A.R.T. are entirely vendor specific and, while many of these attributes have been standardized between drive vendors, others remain vendor-specific.

Micron ssds do not appear to offer a compression feature. Here's an excerpt from Tom's Hardware's review of SandForce 2nd gen ssds ( https://www.tomshardware.com/reviews/vertex-3-sandforce-ssd,2869-3.html ):

Much of the magic in a SandForce-based drive comes from data compression.

.

My preliminary reading about internal ssd compression is that it involves some complex tradeoffs. Seagate recently began offering a compressing ssd; see: https://www.flashmemorysummit.com/Proceedings2019/08-07-Wednesday/20190807_CTRL-201-1_Haratsch.pdf

 

[fzabkar]

Have you seen this thread?

https://forums.anandtech.com/threads/what-up-with-my-crucial-ssds.2576727/

This review explains that Micron's NAND switches between SLC and MLC modes on the fly, even in DRAM based SSDs:
https://techreport.com/review/27105/microns-m600-solid-state-drive-reviewed/

AFAICT, this means that under certain conditions the WAF will be 3:1 for MLC, 4:1 for TLC and 5:1 for QLC.