This firmware will update the MX500 SSD from version M3CR032 to M3CR033. If your SSD has version any version besides M3CR032, this firmware update is not applicable and not necessary. M3CR033 includes the following changes:
Warning: Crucial recommends that you back up or make copies of all important files before installing this firmware update. This firmware updated is done entirely at your own risk. If performed correctly, there will be no loss of system or user data currently stored on the drive. However, if the firmware process is interrupted, your solid state drive might not function properly. If the firmware update is done on a notebook computer, Crucial recommends that the computer is plugged in to avoid interruption.
TLDR: Avoid using Crucial SSDs in your Unraid system. If you are using them, backup all the data immediately, consider replacing them, or at the very least check your firmware version and update to the latest (M3CR046) ASAP.
The only thing that ended up resolving this and stabilizing my cache pool was updating the SSDs firmware to the latest version available, M3CR046 at the time of this post. This update is not available for direct download through the Crucial support site, you must use crucial storage executive software which only runs on Windows. Also the firmware update only works if you are actively writing to the disk (lol)... so this required mounting BTRFS in Windows using WinBtrfs, and writing to the filesystem while you execute the firmware update in the crucial software.
I had a Crucial MX500 in my Unraid system for a a few years. It had the problem described in the post linked by Trurl; pending sector count going to 1 and then magically returning to 0. The solution that worked for me was to disable tracking of attribute 197 in the SSD SMART settings in Unraid. No firmware upgrade would address the issue and, in fact, Crucial started calling it "normal" when it started happening in WIndows as well as Linux.
The firmware release notes from Crucial admit this problem exists. They claim it doesn't affect Windows, which is why I specifically mention "Unraid system" in my original post.
I am just learning of this issue with MX500 drives. Checked my drive and sure enough it has M3CR043 firmware. I have it formatted as an XFS cache drive. It only has appdata and system shares configured to PREFER. I have had it running for about 8 months with no issues (maybe because I'm using XFS?).
So what would be the most painless way to update? Would I change my appdata and system shares to YES and then have mover move those shares to the array. Then powerdown Unraid, remove the drive and put it in a Windows system then format it to NTFS(since my drive is XFS, winbrtfs method doesn't seem like an option). Run Crucial Executive and update the firmware. Should I maybe do a backup of the drive prior to formatting to NTFS, that way I could just restore the XFS format on the drive when done? Not sure how a program like Macrium Reflect would work with an XFS drive backup.
TLDR: You may want to update Crucial SSD firmware if using them in your Unraid system. If you are using them, backup all the data immediately, consider replacing them, or at the very least check your firmware version and update to the latest (M3CR046) ASAP.
After lots of troubleshooting and process of elimination, the only thing that ended up resolving this and stabilizing my cache pool was updating the SSDs firmware to the latest version available, M3CR046 at the time of this post. This update is not available for direct download through the Crucial support site, you must use crucial storage executive software which only runs on Windows. Also the firmware update only works if you are actively writing to the disk (lol)... so this required mounting BTRFS in Windows using WinBtrfs, and writing to the filesystem while you execute the firmware update in the crucial software.
i got my MX500 (500GB) (M3CR045 firmware) on 15/3/23 and connected to the PC via USB - it's not detected by 'My Computer' but detected by Crucial Storage Executive + Speccy + CrystalDiskInfo + HD Sentinel........
After 6 hours (unused) the FTL Program page count is 2866 while Host Program page count is just 2 !! ...........2+ hours later, the FTL Program page count went to 3013 while Host Program page count is only 6............!!.............Total Writes is just 20.48KB...........so does this mean the memory cells will wear out much faster than normal ??
could it be that the FTL Program page count is so high due to HD Tune scan and Crucial Storage Executive extended self-test with reads and writes ??
This SSD has M3CR045 firmware (i heard this firmware has serious issues) so should i update to M3CR046 firmware ?
i also have 2 other MX500 (250GB) - both with M3CR043 firmware and working fine, should i update both of them to M3CR046 firmware ?
after reading about many complaints from people that updated the firmware from M3CR043 to MCR045............i'm really worried things will go wrong since you can't ''go back' 'to the old firmware, right ?
it's on the Storage Executive...........my old MX500 (500GB) from 2019 is on M3CR023 and it's the latest firmware for it............the new one shipped with M3CR045 with option to update to M3CR046.........
i got my MX500 (500GB) (M3CR045 firmware) on 15/3/23 and connected to the PC via USB - it's not detected by 'My Computer' but detected by Crucial Storage Executive + Speccy + CrystalDiskInfo + HD Sentinel........
Nope. Perhaps because mine are all 24/7 and Linux, they never drop into that bottom power state that stops them counting. I've noted there's a post on Servethehome that comments on the 980 Pro with the 5x firmware not counting properly, so it's not just mine.
Yes, using Crucial Storage Executive it says there is a firmware update available for both of them, however when I selected to install it, it fails? I'll try again and give you a detailed description of the error.
Error while checking for firmware updates.
Connection failed because of socket exception when trying to access the firmware web service host. Please try again later or use the manual firmware update process.
I have two of the older (much, much older) Crucial m4 drives that had that bug that once you hit about 5000 hours on it, it basically stops working after being in use for one hour, every hour. Had to go through that manual firmware update process as described above, though I did it with bootable DVDs I think.
I'm not saying you're wrong, I've already said the software is bloated. As have you, multiple times. We get it. I had no issues using it to update the firmware on tens, likely more than a hundred SATA drives used in system builds where I used to work.
First of all, the M3CR023 firmware doesn't work on it ... I got it to boot and all, it says it is applying the firmware update, but on reboot, the original M3CR043 was still shown as the current firmware version.
However, there is a M3CR045 firmware available for drives with N3CR043 firmware. To get Crucial Storage Executive to download and apply it, since there is no standalone download for it, you need to initiate a high workload on the drive (copy a big directory to a network or USB storage device) ... then Crucial Storage Executive won't crap out, it will then be able to apply the firmware update.
To get Crucial Storage Executive to download and apply it, since there is no standalone download for it, you need to initiate a high workload on the drive (copy a big directory to a network or USB storage device) ... then Crucial Storage Executive won't crap out, it will then be able to apply the firmware update.
So even with the new firmware M3CR046, one of the MX500's didn't appear on startup, only I didn't notice for a while because the MX500 SSD that normally does it being Drive 0, was instead Drive 1 this time, so it's like they switched places, anyway, could be just a random one off, I'll see how it goes, a quick restart fixed it.
If you've updated firmware and tried different SATA cables and it's still happening, your next two steps IMO would be to try powering the drive differently (just use a dedicated PSU's SATA power connectors or try a Molex -> SATA off your current PSU) or try the drive in another system.
Provided the firmware on the motherboard does a cascading pass (read: attempts to load from each drive, and on failure continues), you'll have the drive initialised because otherwise the system can't attempt to boot from it. It's an ugly hack from early UEFI boot days.
Eh, I've had more problems with crucial drives than silicon power drives. Had a crucial MX300 525gb that showed a Samsung 840 evo -isk type dataloss failure, even though the drive works fine after erase.
I'd take a drive assembled with an older off the shelf controller, using bog standard and well tested Nand technologies, DRAM or DRAMless (although SATA drives do really need DRAM, NVMe drives on the lower end work perfectly fine with DRAMless designs) from a randomish 3rd party over some you-beaut new technology drive that samsung and crucial like to sometimes inflict on the market.
760c119bf3