IBM is still using Everspin MRAM inside its fifth-generation FlashCore Modules because enormous QLC drives need more than NAND to survive power failures.
According to XenoSpectrum, the FlashCore Module 5, or FCM5, reaches 105.6TB of raw capacity by combining high-density QLC NAND with a smaller amount of non-volatile MRAM. IBM has been using the latter in FlashCore products since 2018.
Everspin fellow Steffen Hellmold highlighted IBM’s continued use of MRAM at the SNIA Developer Conference on 28 September. IBM’s FCM5 board photos show Everspin silicon inside the drive.
It might look peculiar to put one form of non-volatile memory beside another, but the two are doing rather different jobs.
NAND keeps stored data after power is removed, but information arriving at an SSD doesn’t necessarily land immediately in NAND. Controllers still have buffers, journals and metadata recording where writes have gone and what has been updated.
If that information lives only in volatile DRAM, an SSD needs enough emergency power to keep the controller alive while it flushes everything important into NAND. Enterprise drives traditionally achieve this with capacitors, adding components, board space and another engineering nuisance.
IBM’s answer has been STT-MRAM, which retains information without power while offering fast reads and writes. FlashCore can preserve critical journal and write-management information there rather than desperately emptying DRAM when someone pulls the plug.
IBM said its earlier implementation let the controller FPGA shut down within milliseconds after a power loss, instead of staying powered for a lengthy data flush. MRAM does not eliminate every shutdown procedure, but it substantially reduces the work that needs emergency power.
Everspin confirmed in 2024 that IBM’s fourth-generation FlashCore Module used its 1Gb PERSYST EMD4E001G STT-MRAM. That part has a DDR4 interface and a rated read and write bandwidth of 2.7GB/s.
IBM has not disclosed whether the fifth-generation drive uses the same MRAM part or how much MRAM sits inside each module. The real bulk storage remains QLC NAND, storing four bits per cell. IBM uses part of its NAND in SLC mode for incoming writes and frequently accessed data, while colder material migrates into the denser QLC area.
That gives FCM5 three rather different memory jobs. MRAM handles frequently updated management information, the SLC area enables faster NAND access, and QLC provides the capacity needed to turn the drive into a storage brick.
FCM5 moves from the previous U.2 format to EDSFF E3.L and comes in raw capacities of 6.6TB, 13.2TB, 26.4TB, 52.8TB and 105.6TB. IBM credits high-density QLC, component placement, cooling and power-delivery improvements for making the larger capacities practical.
MRAM helps with those physical constraints, but it would be daft to credit it with creating the 105.6TB model on its own. IBM has not published figures showing how much of the capacity gain comes from the MRAM-based power-loss design.
IBM claims hardware compression can reach roughly 3:1 depending on workload, while FCM5’s logical address limit has risen to about six times physical capacity. That does not magically make 105.6TB of NAND store six times as much incompressible data, despite the temptation of gigantic marketing numbers.
The drives perform some deduplication work themselves. Each FCM generates hashes and compressibility information; IBM Storage Virtualise identifies possible duplicates, and the module verifies matching content before mapping it to one location.
FCM5 also includes ransomware detection, although that is separate from MRAM’s role in surviving power failures. The module produces I/O statistics which the array controller evaluates using a detection model.
