In the past, one could almost call the Exos line-up “boring”. We say that as the old joke about them is the ‘E’ stands for evolutionary, not rEvolutionary. Which has more than a smidgen of truth to it… as Seagate is extremely conservative by nature. So when it comes to ‘revolutionary’ style changes to their Enterprise product stack ,they are notorious for slow rollouts… over multiple generations. This conservativism is arguably why HAMR-based technology took so long to first hit the market in a limited basis and longer still to finally hit the ‘retail’ sales stream(s).
In either case the Exos M shares very little hardware with previous Exos X models reviewed. To be precise, they share the same interconnect options (SATA and SAS). They share the same form-factor (3.5-inch). They share the same helium-filled and sealed chassis technology. Some of the components on the PCB are the same (e.g. vibration sensors)… but the important ones are different (finally a true performance SoC!). They share the same colorful white + green labels (albeit with different text printed upon them)… and they share some common firmware command options (e.g. TLER, ISED, etc.) and features (Super-Parity and the like). That’s it. Everything else? It is pretty much different.
If upon first hearing that caused you to suffer from an autonomic response like say an uncontrollable eye twitch… congratulations! You are an “old hand” in the Enterprise IT arena. Like us, you probably hate the word ‘new’ and loathe even the idea of paying for the privilege of using, in a business setting, technology that is still in its infancy (or as we like to say “paying for the privilege of being unpaid beta testers is for losers”). Seagate gets that cynicism and understands why it came about… after all darn near everyone in the industry has at least one “Itanic” type story to tell.
That is (ironically) why they have changed so much in one go. Kind of a ‘rip the band aid off quickly’ type deal rather than their usual M.O. of a slow trickle over generations. The downside is eye twitches in purchasing agents and a massive uphill battle to justify the new technology over ‘tried and true’ models like the last gen 24TB Exos options.
On the positive side, Seagate has gone above and beyond to get you quickly past the cynicism stage and into the grudging respect stage (true “love” or even just true respect will take a proven track record over a minimum of 5+ years). So let’s dig into what has changed. Why it changed… and why it may actually be a Good Thing™.
Let’s start with the firmware… as many a ‘good’ device has been cursed with trash-tier firmware. Turning what should have been firmly on a ‘buy it’ list into one that is on everyone’s blacklist. Unlike Samsung’s SSD division, Seagate’s firmware team actually does not just fling poo at a wall to see what sticks. Everything is researched. Everything is alpha and beta tested. Everything pretty much at least ‘works’. This is why the all-new Multi-Tier Caching (MTC) variant is eyebrow-raising. Basically, and in typical Seagate fashion, not much has changed since the introduction of MTC. Yes. The algorithms get more refined and more powerful every generation… but an actual new variant? Now that is noteworthy.
To be specific, Seagate’s Exos M 30TB hard drive features a refined Multi-Tier Caching (MTC) technology variant that falls under the “Mozaic 3” header and has been non-officially dubbed ‘Mozaic MTC’. This new MTC version is a highly refined set of algorithms that builds on the foundation created by the earlier Exos X24 24TB drives… but with meaningful advancements to better suit the demands of HAMR technology, its much denser platters, and user feedback.
So while both the new M 30TB and ‘old’ X 24TB share the same cache amount (512MB), the way this cache is utilized and organized differs dramatically between the two generations. The Exos X24 treats its RAM cache more as a singular, unified resource primarily split between read and write caching. In practice, the firmware dedicates roughly 60 to70% of this RAM cache to write buffering (e.g. to accelerate random and sequential writes), while the remaining 30 to 40 percentage(ish) is used for read caching to speed up data retrieval. We say ‘ish’ as it was a floating overall percentage that can (and did) vary depending on real-time demands.
This flexibility reflected traditional nearline storage workloads and offers solid all-around performance for enterprise data centers and hyperscale environments alike… and was pretty darn good at meeting non-professional storage enthusiasts’ needs too. Put another way, the X 24TB’s MTC is no joke. Up until now, it arguably offered the best tradeoffs of all the MTC options… and why Exos X models “vampired” many a sale from their IronWolf Pro brethren.
The Exos M 30TB on the other hand, copies more than just a single page from the SKYHAWK AI playbook and (much like that MTC variant) divides its 512MB RAM cache into smaller, specialized segments. Each is dynamically adjusted by advanced firmware algorithms to reflect the real-time demand the drive is being placed under. However, unlike both the SKYHAWK AI and previous Exos X methodology, the new Mozaic MTC radically differs in how the read and write portions are subdivided. With even more flexibility in not just in the total quantity dedicated to read or write, but also how each of the two sub-sub-caches is configured.
To be more precise, the firmware starts out by dedicating a slightly larger portion of the cache (estimated around 55–60%) to write caching and it is no longer a monolithic block (we liked to use the “filing cabinet” analogy for its predecessor); instead, it’s spread across multiple finely tuned sub-buffers optimized for HAMR’s unique laser-assisted write pacing… and while it starts at 55 to 60 percent the learning algorithms can, and will, adjust that percentage based upon real-time write vs. read I/O requests.
Basically, the firmware not only aggressively buffers real-time write requests but also reorders them to reduce random write bursts. It then also times them to match (and smooth out) the laser heating pulses needed for HAMR writes. All of which the previous gen basically either did not do or did so in a very simplistic fashion. The remaining (~40–45%) focuses on aggressive read caching that intelligently prefetches and holds hot data in the RAM cache, improving responsiveness significantly.
At the micro level, the algorithms dedicated to each “mini” cache portion can also differ depending on real-time I/O demands. For example, most of the mini-cache portions will be dedicated towards handling specific workload types like burst writes, sequential streaming, or random I/O…. with a ‘floating’ portion held in reserve to allow for real-time dynamic adjustment of what is being held in the cache and what needs to be ‘flushed’. Regardless of what level you look at this ‘data’ being cached is not necessarily even full files. Rather, when necessary due to high I/O queue depths (for example), the controller will switch to caching just ‘chunks’ of files – similar to how IronWolf MTC does things (albeit in a more refined and precise manner than previous PMR-based ‘Wolf Pro series).
To envision all this, imagine that the older drive MTC was like a company run by luddites. One where the ‘front office’ of the company just stuffs all their purchase order paperwork in one cabinet and stuffs their in expenses another cabinet… and every so often the secretary gets fed up and ‘cleans it all out’ and ships it out to cold storage. Now, for the new wa,y take that same secretary and major filing cabinet analogy… but instead of just one filing cabinet with files and folders in it, there is a row of them. All with either a label that says ‘read’ or “write” in erasable ink.
As requests come in hot and heavy, the ‘secretary’ reorders the requests (possibly even temporarily stacking them on top of a cabinet), then opens the proper folder(s), fills them with paperwork… and/or said paperwork is read from said folders (and/or the paperwork is thrown in the trash or even cold storage). If necessary, she even clears a full drawer out… or even a full cabinet and swaps out the ‘read’ label for ‘write’. Furthermore, all this is being done either in real-time or at least near real-time… depending on what the secretary decides is the most appropriate response at a given time.
These MTC algorithms are then backstopped by extremely aggressive processing and adaptation algorithms that can handle pretty much all the common antics Mr. Murphy gets up to in the Enterprise arena. Key among these algorithms are Automated Multi-Rev Recovery (AMRR) and Automated Adjacent Track Interference Cancellation (ATIC), which boost the reader’s effectiveness and the drive’s overall data integrity.
Automated Multi-Rev Recovery (AMRR) is an advanced data recovery technique designed to salvage data that might otherwise be lost due to temporary read errors or disturbances. In modern high-density hard drives, the read heads fly just nanometers above the disk surface, where external vibrations, slight mechanical misalignments, or media imperfections can cause momentary data reading… glitches. When triggered by the monitoring sensors (that literally are checking each and every bit read or written to/from the platters… in real time) instead of just doing the typical re-read, or a timed (TLER) re-read this new AMRR kicks in.
The first thing AMRR does is automatically trigger multiple re-reads of the same data track (“multi-rev”). It then aggregates the results of these multiple noisy attempts into a cleaner, error-reduced composite via highly advanced algorithms (some of which are actually borrowed from the sound industry). This automated process significantly increases the likelihood of successful data recovery without manual intervention by the RAID controller… or worse, marking it as an Unrecoverable Error and moving on.
Automated Adjacent Track Interference Cancellation (ATIC) addresses a related challenge: interference from magnetic signals recorded on neighboring tracks. As the density of tracks increases, the spacing between them shrinks, raising the risk that signals from adjacent tracks bleed into each other during reading—compromising accuracy. Yes. This is the latest version of what TDMR did in the past. Yes, Just like TDMR in the Exos X 24TB this means twin dynamic read heads are being used. However, it is now using even more sophisticated signal processing and machine learning techniques embedded in the “man in the middle” signal controller. Resulting in the same Unrecoverable Bit Error Rate (UBER) rating of 1 sector per 10^15 bits read… or one UBER per quadrillion bits read (aka 1 per petabit). On a drive using “bits” that are at least 6X smaller than its predecessor.
