~cartwright's Minimalist Blog

The Architecture of Flash: SSDs, Write Cycles, and the Engineering Behind Modern Silicon Storage

July 4, 2026

Introduction: The Shift from Platters to Silicon

For decades, digital storage relied on mechanical magnetic read/write heads hovering nanometers above spinning platters. Hard Disk Drives (HDDs) excelled at linear read/write operations but were fundamentally limited by physics. Solid-State Drives (SSDs) discarded moving parts entirely, replacing mechanical latency with the speed of moving electrons. Yet, silicon storage operates under a completely different, unpredictable set of chemical and electronic rules. To manage these rules, computer engineers had to build complex translation layers that mask the true nature of flash memory from your operating system.

Flash Memory: The Beginning of NAND and NOR

All flash memory tracks back to the invention of the floating-gate transistor (MOSFET). However, the market split early on into two distinct topological architectures named after the logic gates they resemble: NOR and NAND.

NOR Flash: In a NOR configuration, cells are connected in parallel. This allows the system to access individual memory locations directly (byte-addressability). Because it supports random access, it features fast read speeds and allows a processor to execute code directly from the flash chip without copying it to RAM first (Execute-in-Place). However, the parallel wiring requires more physical space, leading to low storage densities and slow write and erase times. Today, NOR is reserved for BIOS chips, routers, and embedded firmware.
NAND Flash: In a NAND configuration, cells are connected in series. This eliminates the bulky wiring of parallel circuits, allowing cells to be packed tightly together for maximum density and low manufacturing costs per gigabyte. The trade-off is that NAND cannot be accessed by individual bytes; it must be read and written in larger clusters called pages, and erased in even larger units called blocks. Because of its massive density advantage, NAND became the undisputed foundation of SSDs, smartphones, and memory cards.

The Battle for Density: SLC to QLC, Trading Longevity for Size

💧 The Bucket Analogy: Why Density Causes Corruption

To visualize this engineering battle, imagine a single flash memory cell as a bucket of water, where the water represents trapped electrons.

SLC (1 Bit): You only care if the bucket is empty (0) or has water in it (1). Even if a few drops spill or some water evaporates over time, as long as there is any water left, the computer safely reads it as a 1. It is incredibly hard to corrupt.
QLC (4 Bits): Instead of empty or full, you must divide that exact same bucket into 16 precise water levels to store different combinations of data.

The Risk of Corrupt Data: Because the physical walls of the cell degrade with use, electrons will slowly leak out. In an SLC bucket, a little evaporation doesn't change the state. But in a QLC bucket, losing just a few drops of water drops you into the wrong level entirely, causing data corruption.

At its microscopic core, a NAND flash cell stores data by trapping electrons inside an isolated pocket (a floating gate). The drive controller determines what data is inside the cell by applying a voltage and measuring how much electrical resistance those trapped electrons create.

As manufacturing advanced, engineers realized they didn't have to treat a cell as just "empty" or "full". By measuring highly precise gradations of electrical charge, they could squeeze multiple bits of data into a single physical cell pocket:

SLC (Single-Level Cell): Stores 1 bit per cell. It only needs to distinguish between 2 voltage states (0 or 1). It is incredibly fast, highly accurate, and handles extreme wear, but it is prohibitively expensive and low-capacity.
MLC (Multi-Level Cell): Stores 2 bits per cell. It must precisely isolate and measure 4 distinct voltage states.
TLC (Triple-Level Cell): Stores 3 bits per cell. It requires managing 8 distinct voltage states within the exact same miniature pool of electrons. This is the current standard for mainstream consumer computing.
QLC (Quad-Level Cell): Stores 4 bits per cell. It forces the controller to map out 16 incredibly precise voltage states. While it yields massive drive capacities at cheap price points, reading and writing becomes an exercise in extreme mathematical precision, which degrades performance and longevity.

NAND Cell Type Comparison

Cell Type	Bits per Cell	Voltage States	Typical Write Endurance (P/E Cycles)	Primary Use Case
SLC	1	2	50,000 to 100,000	Enterprise enterprise logging, military, high-end caching
MLC	2	4	3,000 to 10,000	Industrial hardware, legacy premium drives
TLC	3	8	1,000 to 3,000	Operating system boot drives, gaming consoles
QLC	4	16	100 to 1,000	Mass secondary storage, media archiving arrays

Breaking Through the Sub-15nm Wall: 3D NAND

For years, manufacturers increased SSD capacities by shrinking the physical size of the cells on a flat, two-dimensional plane (2D Planar NAND). However, when cells were shrunk below 15 nanometers, they hit a hard wall of physics. Because the cells were so small and close together, the insulating walls thinned down to a few atoms, allowing electrons to spontaneously leak out via quantum tunneling. This caused severe data corruption.

To bypass this limitation, the industry pivoted to 3D NAND (or V-NAND). Instead of squeezing cells closer together on a flat sheet, engineers built up. They laid down alternating layers of materials and etched deep vertical channels, stacking memory cells on top of one another like microscopic skyscrapers. By expanding into the third dimension, manufacturers could use larger, more stable cell sizes while vastly increasing total capacities. Modern SSDs regularly ship with architectures stacked over 100 to 200 layers high.

The Flash Translation Layer (FTL) and Out-of-Place Writes

Your operating system (like Linux, Windows or macOS) is fundamentally stubborn: it still thinks it is talking to a traditional hard drive. It expects to overwrite data directly by sending a command to change specific sectors in place.

NAND flash cannot do this due to an asymmetry in its physics: Data can be read and written at the Page level, but can only be erased at the Block level. A block consists of dozens or hundreds of pages. If you want to change a single sentence in a text file stored on Page 1 of Block A, the SSD cannot simply overwrite Page 1. It must erase the entire Block A first. But Block A contains other valuable, unrelated files!

To solve this, every SSD includes an onboard microprocessor running an internal map called the Flash Translation Layer (FTL). When you modify a file, the FTL directs the update to a completely clean, empty page somewhere else on the silicon. It then updates its internal map to point to this new location, while marking the old page as "stale" or invalid. This is called an out-of-place write.

Garbage Collection & Wear Leveling: Because the drive keeps abandoning old pages, it eventually runs out of clean space. The FTL constantly runs an background maintenance routine called "Garbage Collection." It identifies a block full of stale pages, copies the remaining good pages to an entirely separate block, and then runs a high-voltage clear command on the old block, restoring it to a clean slate. Furthermore, because flash cells degrade every time they are written to, the FTL utilizes Wear Leveling algorithms to spread incoming data evenly across the entire drive, ensuring no single block burns out prematurely.

The SMR Equivalent in the SSD World: Caching and ZNS

In mechanical hard drives, Shingled Magnetic Recording (SMR) is a trick used to boost drive density by overlapping write tracks like shingles on a roof. While SMR drives read data perfectly fine, writing data requires them to carefully rewrite adjacent overlapping tracks, resulting in horrible write performance drops during heavy, prolonged random workloads.

The SSD world deals with its own version of this exact performance dynamic, driven by QLC NAND and caching layers:

Pseudo-SLC Caching (The Behavioral Equivalent): Native QLC memory is incredibly slow to write to because the controller has to carefully calculate 16 precise voltage points. To hide this lag from users, manufacturers set aside a portion of the drive to run as a "Pseudo-SLC Cache". When you write files to the drive, the controller temporarily treats those cells as fast 1-bit SLC cells. However, if you perform a massive, sustained file transfer that exhausts this temporary cache, the drive's performance collapses. The controller is suddenly forced to accept new data while simultaneously transferring and compressing the old data from the SLC cache into slow 16-state QLC cells.
Zoned Namespaces (The Architectural Solution): Much like high-end cloud datacenters use host-managed SMR drives to control precisely where data lands on spinning disks, modern enterprise NVMe drives utilize Zoned Namespaces (ZNS). ZNS bypasses the traditional FTL map entirely. It exposes the raw internal physical blocks of the flash drive to the operating system as isolated, sequential-write zones. By aligning the OS file system directly with the physical geometry of the NAND, ZNS completely eliminates unpredictable internal garbage collection cycles, lowers write amplification, and heavily extends the physical life of the drive.

Critical Vulnerabilities: Power Failures and Bricking Risks

While SSDs are impervious to drops and physical vibration, they are uniquely susceptible to catastrophic sudden power loss.

Because writing data to NAND takes time and requires complex lookup tracking, SSDs rely heavily on super-fast, volatile DRAM chips to act as a workspace cache. This DRAM holds the incoming files and the master FTL mapping layout. If a user pulls out an external drive or suffers a sudden power failure mid-operation, whatever data is sitting inside that volatile DRAM cache is lost.

The real danger here isn't just losing your open document—it is FTL corruption. If the power cuts while the FTL is actively modifying its master map, the directory file can become corrupted or truncated. When power returns, the SSD controller boot sequence reads a broken map and completely forgets where its millions of pages are physically stored. The drive instantly goes into a panicked, locked state, showing up to the computer as an unreadable, uninitialized device with a capacity of 0 bytes. The drive is effectively "bricked".

Enterprise drives protect against this with Power Loss Protection (PLP): a row of hardware capacitors that hold a few milliseconds of emergency backup electricity—just enough time for the controller to safely flush the volatile FTL map down into safe, permanent silicon before shutting off.

The Quiet Decay (Bit Rot): Long-Term Data Retention

⚡ The Silent Repair: Block Refresh Algorithms

To fight this constant leakage, some modern drive controllers use an internal maintenance system called a Block Refresh Algorithm. Think of it as a hidden patrol guard that checks the water levels in every bucket.

Active Scanning: While the drive is powered on, the controller quietly reads data blocks in the background, checking to see if their voltage levels have started to decay.
Rewriting to Repair: If the controller detects that electrons are dangerously close to leaking past a readable threshold, it copies that data to a brand-new, healthy block and marks the old one for erasing.

The Catch: This self-repairing process cannot happen if the drive is sitting unpowered in a drawer. Furthermore, the scan runs at a low priority so it doesn't slow down your daily work. For a large drive to completely cycle through and refresh all its old data, the computer often needs to be left turned on and idle for multiple days at a time.

Many customers incorrectly treat flash drives and SSDs as permanent archival vaults. They are not. NAND flash is a form of electronic storage that relies on physical insulation, not permanent chemical states.

The electrons inside a NAND cell are trapped behind an ultra-thin insulating barrier of silicon oxide. Every single time a cell undergoes a Program/Erase (P/E) cycle, the high voltage applied physically degrades this atomic insulation layer. Over time, the wall develops tiny, microscopic fractures.

If an SSD is left unpowered sitting in a drawer, those trapped electrons will slowly leak out through the degraded insulation over time—a phenomenon called charge migration. Eventually, the voltage level drops past a readable threshold, causing "bit rot" and unrecoverable data corruption. While a brand-new, healthy drive can retain data unpowered for a few years, an old drive that has consumed most of its rated write cycles can begin losing its data integrity after just a few months of sitting completely unpowered, especially if stored in hot environments.

Solid-State Technology Time lines

1984: Dr. Fujio Masuoka invents both NOR and NAND flash memory while working at Toshiba, laying down the theoretical and physical groundwork for all modern solid-state storage.
1989: Toshiba releases the world’s first commercial discrete NAND flash chip to market.
1991: SanDisk builds the first commercial 20 Megabyte PC Card SSD for IBM ThinkPad laptops, costing upwards of $1,000.
2003: The storage industry begins its first massive scale transition from high-cost, low-capacity consumer SLC chips over to multi-bit MLC cells.
2009: Mass commercial production of TLC flash memory arrives, drastically lowering cost barriers and accelerating the displacement of mechanical HDDs as primary boot drives. SanDisk and Toshiba demonstrate QLC.
2013: Samsung breaks the physical planar layout limit by pioneering V-NAND (3D NAND), commercially stacking memory cells vertically for the first time.
2018: High-density QLC consumer SSDs hit the broader retail market, introducing affordable multi-terabyte internal solid-state form factors.
2021: The NVM Express consortium officially rolls out the Zoned Namespaces (ZNS) standard into the core NVMe 2.0 technical specification blueprint, providing hyperscale cloud architectures with direct physical management over silicon storage layouts.

The 4th of July: How fireworks, and sparklers work 4th of July special

July 4, 2026

The Launch & Ejection

Aerial fireworks use black powder to launch a shell into the air. At peak altitude, an internal burst charge detonates, violently ejecting small pellets of metal powder and oxidizers (called "stars") into the sky.

Sparklers do this on a slower scale. A chemical fuel and metal grains are glued to a wire with a binder. As the binder burns down, gas expansion continually throws off tiny, molten metal particles into the air.

Rapid Oxidation & The Glow

Once these metal particles are ejected, they hit extreme heat and open oxygen. Internal oxidizers release oxygen, causing the metals to burn intensely. This rapid oxidation releases a massive amount energy, causing the metal to glow brightly through two methods:

Incandescence: High heat makes solid metal particles glow white or gold.
Luminescence: Energy excites electrons in the gas phase; when they drop back down, they emit specific colors.

The Metal Color Palette

The specific metal mixed into the composition dictates the exact color or effect you see:

Metal Element	Visual Effect / Color
Iron / Steel	Classic golden, branch-like sparks (the backbone of backyard sparklers)
Strontium	Deep Red
Barium	Vibrant Green
Copper	Electric Blue (the hardest to produce & expensive)
Sodium	Intense Yellow
Magnesium / Aluminum	Blinding White / Silver flashes

Happy 4th of July! Enjoy the show and stay safe.

47,000 Hours, Zero Bad Sectors: Why My 2011 WD Scorpio Blue Keeps Working

Jun 27, 2026

We have all been conditioned to accept the inevitable failure of spinning rust. Hard drives are complex mechanical systems with microscopic tolerances, constantly fighting friction, thermal expansion, and physical wear. Conventional wisdom says that after 3 to 5 years of heavy daily usage, a consumer hard drive will start throwing reallocated sectors before finally breaking down.

Yet, the drive I am typing this blog post from completely defies that logic. Sitting inside my laptop right now is a 2.5-inch Western Digital Scorpio Blue manufactured back in 2011. This isn't a drive I just dug out of an old storage bin; it is a drive that has been actively running, and one that I have personally watched the S.M.A.R.T. health logs of for years. I am continually amazed to see absolutely zero problems.

The S.M.A.R.T. Stats

Drive Model: WD Scorpio Blue WD1600BEVT (2011, 2.5-inch)
Power-On Hours: ~47,000 Hours (Over 5.3 Years of Net Runtime)
Reallocated Sectors Count: 0
Current Pending Sectors: 0
Status: Healthy

Forty-seven thousand hours of real-world, active usage, and not a single bad sector. Amazed by this incredible longevity, I decided to do some deep research into the engineering history of this specific era of Scorpio Blue drives to find out why it still works perfectly today.

The Secret: A Single Glass Platter

When I dug into the internal architecture of this drive, I discovered something fascinating about its build. While Western Digital’s official documentation completely sidesteps naming the raw materials—likely because marketing teams worried the word "glass" would scare customers into thinking the drive was fragile. By tracking down industry supply chains, I found out that the glass-ceramic substrate was actually sourced from the HOYA Corporation.

To confirm this for my exact model, I looked up pictures of its interior. Seeing the inside of the drive makes it immediately obvious: when platters are made of glass-ceramic, they lose that bright, shiny, mirror-like chrome look found on traditional aluminum ones. Instead, they have a distinctly deep, darker, and slightly translucent appearance because of how the magnetic layers bond to the underlying glass core.

Glass platters were a massive engineering milestone. Glass is structurally stiffer and far more thermally stable than aluminum. In a drive that sees constant daily use, temperature fluctuations can cause aluminum to microscopically expand and warp, which leads to head-tracking errors and bad sectors. Glass, however, maintains its perfectly flat shape regardless of how warm the drive gets, ensuring flawless head tracking over decades of continuous spinning.

The Magnetic "Paint" Coated Layer

The magic doesn't stop at the glass itself. For data to actually be written, that glass platter has to be coated in a magnetic medium—what engineers of the era sometimes colloquially referred to as a "magnetic paint," though it is vastly more complex than a standard coat of pigment.

In these drives, Western Digital used an incredibly precise thin-film deposition technique. This magnetic coating consists of a cobalt-chromium-platinum alloy applied in microscopic, uniform layers over a glass-polishing base. Because glass can be polished to a significantly smoother finish than aluminum, this magnetic layer could be applied with extreme uniformity. No microscopic bumps meant no accidental contact between the head and the disk, drastically reducing the risk of a catastrophic head crash over my thousands of hours of usage.

Built-In Mechanical Protections

Hardware composition is only half the battle; Western Digital's built-in mechanical behaviors played a massive role in keeping my drive alive:

SecurePark Technology: This system ensures that the recording heads are physically away from the disk surface during spin-up, spin-down, and whenever the drive idles. The head never parks on the data zone, meaning it never rubs against that precious magnetic "paint," eliminating wear from friction.
WhisperDrive Algorithms: These algorithms smooth out the movements of the actuator arm. By eliminating abrupt, jerky movements as the head hunts for data, it minimized mechanical stress on the arm bearings and lowered heat generation.

Final Thoughts: A Masterclass in Legacy Engineering

Watching this drive pass every health check year after year has been incredible. Discovering that it relies on a single, perfectly smooth glass platter coated in a resilient magnetic matrix explains exactly why it refuses to fail. It represents a peak era of mechanical storage engineering—a time when the 2.5-inch form factor was perfected right before Solid State Drives took over the market.

My Scorpio Blue is a living testament to what happens when material science, structural engineering, and firmware align perfectly. It continues to spin, read, and write without a single problem.

Rolling My Own: Leaving Bashblog for Perl 5.8

Jun 26, 2026

For a while, bashblog did exactly what I needed it to do. It was a single script, it didn't require a database, and it kept things out of the corporate cloud. But eventually, the cracks started to show. The moment you want to fix the markdown formatting issues, change how files are structured, tweak the layout logic, or manage index compilation without losing your mind, hacking away at a massive shell script feels less like minimalism and more like fighting a tool that wasn't built for your specific workflow.

So, I did what anyone would do: I went looking for an alternative.

The state of modern web software is excessively bloated. I spent a couple of hours digging through the current landscape of "lightweight" blogging engines and static site generators. Most of what I found was bloated beyond belief—engines wrapped in heavy JavaScript frameworks, massive Python dependency trees, used overly complex PHP (not that I have anything against PHP on its own) or tools that require pulling down hundreds of megabytes of packages just to compile a few plain text files into HTML. Even the self-proclaimed minimalist options still felt over-engineered for what should be a simple text-processing pipeline.

Nothing was even close. If you want something done cleanly without the extra weight, you usually have to write it yourself.

The final spark came when I was looking through Levi's website repository and saw their newpost.sh script. It’s a beautifully simple, no-nonsense shell utility designed to stream-line making a new entry. It reminded me how straightforward the process should be. But instead of sticking strictly to a shell script pipeline for the entire compiler backend, I wanted a dedicated language built from the ground up for heavy text manipulation.

I decided to roll my own static site compiler in Perl 5.8.

Yes, Perl 5.8. It’s a tool from a different era, but it is absolutely unbeatable. It is blazingly fast, runs natively on virtually any Unix-like box you throw it at, handles regular expressions like second nature, and has zero external runtime dependencies.

My new setup reads basic text files with custom metadata headers, runs them through a simple template block, and compiles the entire site—including the master index and an RSS feed—in just a few milliseconds. No Node modules, no complex database configurations, and no overhead. Just raw text, strict logic, and clean HTML.

It feels good to finally have a setup where I know exactly what every single line of code is doing.

Architectural Analysis: CMR vs. SMR Hard Drive Technologies (I know this is not written in the blog tone)

Jun 25, 2026

A Comprehensive Study on Data Corruption, Power Failures, Copy-on-Write Filesystem Incompatibilities, and the Contemporary Market Landscape

1. Technological Foundations: CMR vs. SMR

Hard disk drive (HDD) architectures rely on magnetic recording techniques to read and write data onto spinning platters. As physical storage demands surpassed theoretical areal density limits, manufacturers shifted from standard Perpendicular Magnetic Recording (PMR) variants to two primary operational models: Conventional Magnetic Recording (CMR) and Shingled Magnetic Recording (SMR).

Conventional Magnetic Recording (CMR): In a CMR drive, physical data tracks are written parallel to one another across the disk surface without any overlap. The write head, which is physically wider than the read head, writes a track size that matches its footprint exactly. Read operations occur directly over the center of these distinct, separated tracks. This guarantees that writing to an individual sector has absolutely zero impact on adjacent blocks, allowing for predictable, sustained random write behaviors.

Shingled Magnetic Recording (SMR): SMR modifies this physical layout to overcome the physical limits of track narrowing. Because read heads are substantially smaller than write heads, SMR overlappingly writes data tracks, mimicking shingles on a residential roof. Each new track partially covers a portion of the previously written track. While this drastically increases areal density (up to 25% or higher per platter), it introduces a critical structural limitation: a track cannot be overwritten individually without corrupting or destroying the data on the adjacent tracks that overlap it.

Core Architecture Comparison

Metric / Feature	Conventional Magnetic Recording (CMR)	Shingled Magnetic Recording (SMR)
Track Structure	Isolated, parallel tracks with guard bands.	Overlapping tracks resembling roof shingles.
Random Write Performance	High and predictable; direct sector overwrite.	Extremely low under sustained loads; requires full zone rewrites.
Internal Architecture	Direct pass-through mapping from OS to physical sectors.	Uses a complex Drive-Managed Translation Layer (similar to SSD FTL).
Best Suited For	NAS, RAID arrays, Databases, Boot drives, High-write environments.	Archival storage, sequential backups, cold data storage.

2. Operational Mechanics & Drive-Managed Architecture

To make SMR drives backwards-compatible with standard computer architectures, manufacturers developed Drive-Managed SMR (DMSMR). The host operating system treats the device as a standard random-access sector block device, unaware of the physical shingling layout. To handle the overwrite limitation, the disk surface is segmented into 'Bands' or 'Zones' (typically 256 MB or higher in size), bounded by non-overlapping isolation guards.

When a single sector within an SMR zone must be modified, the drive cannot simply flip the magnetic orientation of that specific sector. Instead, it must read the entire zone into a cache, alter the targeted sector in volatile memory, and write back the entire zone sequentially from the beginning.

To mitigate the severe latency penalties of this process, DMSMR drives integrate a high-speed volatile RAM cache alongside a physical, non-shingled CMR 'landing zone' on the outer edge of the platters. Incoming write operations are initially routed directly to this fast CMR cache. When the drive is idle, an internal garbage collection algorithm executes background migrations, reading data from the CMR cache, combining it, and writing it sequentially to the shingled zones.

3. Power Failure Vulnerabilities & Internal Data Corruption

The illusion that an SMR drive behaves exactly like a CMR drive is maintained by an internal abstraction layer known as the Drive Translation Layer (DTL) or Device Managed Translation Layer. Similar to the Flash Translation Layer (FTL) in Solid State Drives (SSDs), the DTL translates logical block addresses (LBAs) requested by the operating system into physical addresses on the shingled platters. This architectural dependency creates acute vulnerabilities during sudden power loss events.

Critical Risk: Drive Translation Layer Corruption

A sudden loss of system power during active background garbage collection or zone allocation table flushes can cause a complete mismatch between the DTL lookup table and the physical sectors on the platters, effectively bricking or destroying data readability across healthy portions of the disk.

Specific corruption modes directly tied to SMR power failure profiles include:

Metadata and Allocation Table Desynchronization: SMR drives maintain tracking metrics regarding active zones, clean zones, and CMR cache maps. If a power failure occurs while the drive is writing updated allocation tables from internal RAM to a persistent system track, the DTL can become corrupted. Upon reboot, the drive may fail to initialize, report a RAW filesystem, or register incorrect disk sizes (e.g., 0 bytes), requiring specialized hardware-level physical restoration.
In-Fight Zone Overwrite Destabilization: If power is interrupted while the drive is executing a full-zone rewrite (shingling back modified data), the sequence will cut off mid-zone. Because the track write head partially covers adjacent tracks during operation, an incomplete write compromises not only the specific block intended for modification but also destroys valid downstream user data located in adjacent, overlapping tracks within the same zone.
Volatile Write-Cache Data Loss: SMR drives acknowledge writes to the host operating system immediately upon reaching the volatile RAM cache or the CMR landing zone. In a power loss event where the OS has received a write verification, data that was still residing strictly in volatile RAM, or data queued for migration from the CMR cache to the shingled space, vanishes entirely. This leads to profound metadata inconsistency between the OS filesystem and the physical disk.

4. The Copy-on-Write (CoW) Conflict: ZFS / Btrfs / bcachefs and SMR Drives

The deployment of Drive-Managed SMR drives within Copy-on-Write (CoW) filesystems, such as ZFS, Btrfs, or within software RAID architectures (like mdadm or TrueNAS Core/SCALE), represents a severe operational mismatch. ZFS was fundamentally designed with the assumption that the underlying physical storage medium is a deterministic, fast-response block device that handles random and sequential write commands predictably.

ZFS optimizes write pathways by gathering allocations and committing them via transaction groups (txgs) through a Copy-on-Write methodology. Instead of modifying blocks in-place, ZFS writes modified data to entirely new physical locations on the disk, subsequently modifying pointers up the metadata tree. This architectural design creates a highly destructive cascading performance cliff when paired with SMR technology.

The Resilvering and Timeout Cascade Failure

When a standard drive fails inside a ZFS VDEV (Virtual Device), a replacement drive is added, initiating a process known as resilvering. Resilvering scans the entire pool's metadata and writes the parity-constructed data back to the new drive. Because ZFS traverses metadata trees sequentially by object rather than physical sector order, the resulting write distribution looks highly randomized to the target drive.

When an SMR drive is introduced as a resilver target, the following failure sequence occurs:

Initial streams fill up the SMR drive's on-disk CMR landing zone cache almost instantly (typically within the first tens of gigabytes).
Once the CMR cache is fully saturated, the drive's firmware forces an immediate, non-interruptible garbage collection loop to clear space, trying to read-modify-write data out to shingled zones.
Because the incoming write stream is ongoing and highly fragmented, the drive must continuously execute zone rewrites. Data throughput collapses from ~150 MB/s to single-digit megabytes per second, or stalls completely.
The internal drive controller becomes so overwhelmed with background input/output operations that it ceases responding to external ATA command requests from the operating system host bus adapter (HBA).
The ZFS kernel module waits for a predetermined command timeout threshold (typically 30 seconds). When the SMR drive fails to respond within this window, ZFS assumes the drive has suffered a hardware failure or disconnected completely.
ZFS ejects the drive from the pool, marking it as FAULTED or REMOVED.

Systemic Pool Degradation Danger

If multiple SMR drives are present within a RAIDZ array, the intensive write activity of a single resilver can cause multiple drives to hit the latency timeout threshold simultaneously. This triggers a multi-drive drop out, leading to immediate pool destruction and total data loss.

5. Improper Drive Shutdown Timelines and Host Violations

When a computer operating system initiates a shutdown or unmount sequence, it issues strict architectural commands to all connected storage media. This involves sending an ATA FLUSH CACHE command followed by standby or power-down directives. For a standard CMR drive, processing a flush command is simple: any write commands remaining in the volatile onboard RAM cache are instantly flushed to their permanent, non-overlapping track locations, and the drive heads park safely within milliseconds.

For a Device-Managed SMR drive, a FLUSH CACHE command behaves in a fundamentally different and non-deterministic manner. The drive's internal firmware considers data 'flushed' when it has successfully cleared volatile RAM and moved it into the permanent, non-shingled CMR landing zone cache. It then reports success back to the operating system.

Crucially, the hard work of migrating data from the CMR landing zone into the shingled bands has not yet occurred. The drive firmware requires an extended period of system inactivity (frequently stretching into minutes or hours after data transfer stops) to perform background zone consolidation.

If an operational environment utilizes improper drive shutdown timelines—such as immediately cutting power to external drive enclosures, hard-resetting enterprise servers via IPMI commands, or pulling portable USB-powered drives right after a file copy indicator completes—the drive is abruptly de-powered while its background firmware is actively running. Over time, these interrupted states cumulatively degrade the efficiency of the internal allocation tables, leading to sector tracking errors, read latency anomalies, and progressive file structure degradation.

6. Historical Timeline of SMR Market Integration

The introduction of SMR into the commercial market was characterized by an initial phase of transparent archival targeting, followed by a highly controversial period of unannounced integration into mainstream desktop and NAS product lines.

2013-2014: Initial Introduction – Seagate introduces the first commercial SMR drives under the 'Archive HDD' nomenclature. These drives were clearly designated for cold storage, data preservation, and sequential access profiles. They were explicitly marketed as inappropriate for random write, server, or RAID workloads.
2015-2018: Stealth Integration – As manufacturers hit density limits on standard 1TB and 2TB per platter configurations, they quietly integrated Drive-Managed SMR into standard 2.5-inch mobile notebook drives and lower-tier 3.5-inch consumer desktop drives without explicitly documenting the change on spec sheets.
2018-2019: Expansion into Network Attached Storage (NAS) – Western Digital began substituting CMR configurations with SMR designs inside its highly popular WD Red NAS line (specifically the 2TB through 6TB models, such as the WD40EFAX), completely undocumented.
2020: The Industry Transparency Scandal – System administrators and home server enthusiasts worldwide began noticing catastrophic RAID degradation and resilvering failures when deploying newly purchased WD Red drives. Following intense public backlash, independent hardware investigations, and threatened class-action litigation, Western Digital, Seagate, and Toshiba were forced to publish complete, comprehensive disclosures detailing exactly which drives utilized SMR. Western Digital subsequently re-branded its product stack, keeping SMR in the baseline 'Red' tier, while introducing the 'Red Plus' and 'Red Pro' lines to guarantee CMR availability.

7. Contemporary Market Reference Guide

The following guide highlights the architectural layout of the modern hard drive marketplace. Consumers and enterprise engineers must rigorously parse model numbers to ensure SMR models do not enter high-availability or CoW environments.

Manufacturer	Product Line / Brand	Recording Technology Type	Capacity Thresholds & Notes
Western Digital	WD Blue (Desktop 3.5")	SMR (Majority) CMR (Select models)	Most 2TB, 3TB, 4TB, and 6TB variants are SMR. High-capacity or specific 1TB models remain CMR.
Western Digital	WD Red (Standard NAS)	SMR (All)	Models from 2TB to 6TB (e.g., EFAX series) are strictly SMR. Banned for ZFS usage.
Western Digital	WD Red Plus / Red Pro	CMR (All)	Explicitly designated for RAID/NAS arrays. Guaranteed CMR across all capacities.
Western Digital	WD Black / WD Gold	CMR (All)	Performance and Enterprise lines; exclusively CMR across all capacities.
Seagate	BarraCuda (Compute 3.5")	SMR (Majority)	Mainstream desktop lines (2TB, 4TB, 8TB) are SMR. Explicitly designed for light compute only.
Seagate	IronWolf / IronWolf Pro	CMR (All)	NAS-focused product line. Seagate maintains a strict no-SMR policy for all IronWolf models.
Seagate	Exos (Enterprise)	CMR / HM-SMR	Standard Exos models are pure CMR. Select cloud hyperscale models use Host-Managed SMR (managed by server OS).
Toshiba	P300 (Client Desktop)	SMR / CMR Split	Newer high-capacity iterations (e.g., 4TB, 6TB P300) are SMR. Older or lower capacity models remain CMR.
Toshiba	N300 / MG Series	CMR (All)	NAS and Enterprise Critical lines; exclusively CMR across all production models.

Summary Recommendation for Storage Engineering

For any deployments involving ZFS, RAID configurations, high-frequency database logging, or critical infrastructure, it is absolutely essential to mandate the purchase of drives explicitly validated as CMR (such as WD Red Plus, Seagate IronWolf, or Enterprise lines). SMR drives must remain strictly quarantined to sequential cold-archival write streams or disconnected single-drive consumer backup tasks.

From Claude Code to Micro-Agent: The Rabbit Hole of AI Coding Agents on Vintage Hardware

Jun 23, 2026

Every developer knows the feeling. You see a shiny new tool, your brain sparks with possibilities, and you immediately try to run it on hardware that has no business hosting it(well maybe only me).

This is the story of how a simple desire to try Claude Code led me down a rabbit hole of instruction set failures, API translation layer frustration, context-window blowouts, and ultimately, writing my own lightweight AI coding agent in Ruby.

---

The Catalyst: Fighting with Claude Code

It started innocently enough. I wanted to see what Claude Code could do.

My weapon of choice? An old, trusty Dell laptop powered by an Intel Core 2 Duo P8700 processor. I kicked off the installation, only to watch it pull down a massive package over 280MB in size. For a CLI tool, that felt extremely bloated.

But the real kicker came when I tried to run it:


Illegal Instruction

The harsh reality of legacy hardware hit home. Claude Code (or its underlying Node binaries) compiled down to modern instruction sets requiring AVX and AVX2, extensions that my Core 2 Duo completely lacks. 280MB of bandwidth, gone.

The Pubnix & Proxy Detour

Refusing to give up, I shifted tactics and moved to a pubnix (a public UNIX server). Of course, running an AI agent on a shared public server comes with an obvious caveat: someone could easily sniff your process arguments or environment variables and steal your API key. Worse yet, I didn't actually have a dedicated Anthropic API key on hand. I wondered: How hard could it be to use an Anthropic-to-OpenAI API translator?

I found two translation projects via a quick web search. What followed was a classic developer nightmare: Python version conflicts, NPM dependency hell, and incompatible environments. Frustrated, I sat down and wrote my own custom API translator from scratch.

It finally ran! I hooked up Claude Code to my translator, typed a command, and... absolute silence.

Only the basic /btw command functioned. The moment Claude Code tried to do anything involving actual file editing, it failed completely. As it turns out, Claude Code passes a gargantuan list of tools and system instructions out of the box. This massive payload instantly saturated the OpenAI-compatible endpoint's context limit.

All that work, and the context window choked before the model could even think.

---

The Birth of `Micro Agent`

If you can't use a heavy tool, you build a precise one. I abandoned the bloated frameworks and wrote a lean, custom AI coding agent called Micro Agent, implemented as a lightweight Ruby CLI.

Micro-Agent features a flexible architecture allowing it to pivot between different LLM backends using profile commands. To test it, I decided to give it a classic litmus test: Write a simple program to output "Hello, World!" in amd64 NASM assembly for Linux, along with a Makefile to compile it.

I hooked it up to a local, smaller model profile (gemma4:e2b) to see how an optimized, smaller intelligence would handle low-level engineering tasks. What followed was a glorious, looping comedy of errors.

---

The Battle of the Assembly Code: A Log Summary

While Micro-Agent successfully integrated with system tools, the smaller model architecture struggled immensely with syntax, build systems, and execution guardrails. It took far more prompts and manual intervention to get a "Hello, World" binary compiled than it ever would have taken to write it by hand.

Here is the condensed, sanitized screen dump showing the agent trying to complete the task:

ben@box5:~/Projects/micro-agent/a$ ../micro-agent.rb 💻 Welcome to MicroAgent CLI micro-agent > /api use 0 🎯 Switched active profile targeting to Context ID Engine Node: [0: gemma4:e2b] micro-agent > make a simple program to say "Hello, World!" in amd64 NASM for linux, and make a makefile for it 🤖 Thinking... Writing hello.asm and initial Makefile... ... [15+ Security Gate Permission Prompts Condensed] ... ❌ FAILURE 1: The model generates a flawed Makefile with invalid space indentation. 'make' throws a "missing separator" syntax error. 🤖 Thinking... Correcting Makefile syntax... ❌ FAILURE 2: The model rewrites the Makefile but ruins the dependency logic, blindly repeating strings and breaking standard GNU Make patterns. 🤖 Thinking... Attempting to execute 'make' again... Target fails. ❌ FAILURE 3: The model decides to bypass 'make' entirely and chain commands via the shell: 🛠️ Executing: execute with args: {"command"=>"nasm -f elf64 hello.asm -o hello.o && ld hello.o -o hello"} ⚠️ Execution blocked! The micro-agent core engine explicitly bans command chaining (&&) for security. ❌ FAILURE 4: The model attempts a raw NASM compilation but fails because it used Python/C shell style '#' characters for comments inside hello.asm. micro-agent > nasm does not support using '#' for comments, use ';;' instead. 🤖 Thinking... Rewriting hello.asm with proper ';;' comment syntax... ... [More Permission Prompts] ... micro-agent > run the make command ❌ FAILURE 5: The model panics, completely loses track of the directory state, deletes/overwrites the Makefile with broken targets, and accidentally purges hello.asm. When it tries to recreate hello.asm, the user manually rejects the file write out of sheer exhaustion.

⚠️ [Security Gate] Grant agent permission to 'write_file' on 'hello.asm'? (y/n): n ✅ Objective reached or agent stopped.

Taking Back Control

At this point, the agent hit an environmental wall, forcing me to temporarily suspend the process (^Z) and inspect the damage.

The agent had left behind an absolute mess in the build script (build.sh). It had attempted to use gcc to link a raw entry-point assembly file. When executed, the GNU linker threw a massive fit:


> /usr/bin/ld: hello.o: in function `_start':
> hello.asm:(.text+0x0): multiple definition of `_start';
> (.text+0x17): undefined reference to `main'
> collect2: error: ld returned 1 exit status

Because gcc automatically injects the standard C runtime (crt1.o), it provides its own _start symbol and looks for a developer-defined main function. My assembly file explicitly defined _start and lacked a main.

To fix it, I manually bypassed the broken script and linked it directly using the raw linker:


ben@box5:~/Projects/micro-agent/a$ ld hello.o -o hello
ben@box5:~/Projects/micro-agent/a$ ./hello 
Hello, World!
Segmentation fault

Success... followed immediately by a Segmentation Fault. The agent's code printed the string via system calls but failed to clean up the stack or invoke the proper sys_exit sequence. I had to manually jump into emacs to fix the register placements and structural bugs inside hello.asm myself until it finally executed cleanly.

When I brought Micro-Agent back to the foreground (fg) and asked it to review the modifications, it admitted its own execution blindness, noting that security restrictions prevented it from testing its own output.

---

Lessons Learned

Model Size Dictates Logical Rigor: Small local models like gemma4:e2b are fantastic for text processing or basic scripts, but they break down when navigating multi-step compilation pipelines. They struggle to retain context over strict formatting rules (like Makefile tabs vs spaces) and will loop endlessly when a command fails.
Larger Contexts Shine: When switching Micro-Agent over to heavier, remote configurations—such as openai/gpt-oss-120b—the loops disappear. Higher-parameter models anticipate linking requirements, comment rules, and runtime environments effortlessly.
The Irony of Automation: Sometimes, setting up an autonomous agent to automate a 10-line assembly script takes 10x more time, prompts, and debugging than just pulling up a text editor and typing the assembly code out yourself.

Yet, despite the hiccups, Micro-Agent works. It's ultra-lightweight, it runs on virtually any machine, it doesn't suffer from modern instruction set bloat, and it keeps the developer firmly in control of the security gates. For vintage laptop enthusiasts and minimalist developers alike, building your own agent is a journey well worth taking.

---

How I got started programming

Jun 22, 2026

I decided to write down a bit about how I originally got into computers and coding. It all started when I was 12 years old, when my dad taught me Perl. That was my first real introduction to writing scripts and getting things to run.

After that, I just kept building on it. For the next 12 years, I spent my time diving into different systems and learning a bunch of languages.

The Toolkit

During those 12 years, I heavily focused on learning C, C++, Java, ASM (x86), and Ruby. Working with x86 Assembly and C gave me a good understanding of low-level systems, while Ruby became a great tool for writing clean scripts.

Along the way, I also picked up a little bit of Rust, Python, and Perl 6 (raku). To figure out how the web side of things worked, I learned javascript and some web design stuff, like html, css, and a little bit of xhtml.

Down to the Silicon

As I got deeper into programming, I wanted to know exactly how everything worked under the hood. Over the years, I've learned pretty much everything about computers from the chipset and bootloader level on up.

Instead of treating operating systems like a black box, I've spent hours exploring the NetBSD and Linux source code to see how they handle things at the core. To actually apply that, I've built a simple bootloader from scratch, written my own kernel, and even patched BIOS images to manually unlock hardware virtualization features like VT-x.

New version of searchvista is out!

May 14, 2026

New version features better search results, and faster search times. Next month (June 14th 2026), We will be trying out pagerank.

PageRank

PageRank is an algorithm for measuring a webpage's relative importance or authority based on its link structure. It works by treating links as "votes" where votes from more authoritative pages count more. So like if tilde.club is pointed to my 15 other sites, that means that tilde.club will have a higher score, and the score will be even better if the those 15 sites were pointed to by someone else, the more sites on the tree pointing torwards tilde.club the better score. Not all votes are equal because a site with many links dilutes its own power.

Switching to Window Maker from TWM

April 30, 2026

Much smoother than TWM for normal use.

Another post

April 02, 2026

Another post about nothing.

Switching to TWM from GNOME

January 21, 2026

Switched to TWM from GNOME, because gnome takes nearly 15% CPU while idle, and while playing video about 200% CPU usage.

SearchVista mirror systems upgrade

January 11, 2026

Upgrade went smooth and only 1 minute of down time!

SearchVista mirror systems software upgrades