Search
All content
Project
Cookies and browser storageConfigured optional services, local preferences and privacy choices.
Guide
Storage reading pathsReliability, recovery, performance and flash reading paths.
Tool
Storage calculatorsTBW and DWPD, transfer time and RAID capacity with explicit assumptions.
Project
About HeselaAbout Hesela. Information from the Hesela team.
Project
Editorial standards and correctionsEditorial standards and corrections. Information from the Hesela team.
Project
Contact the Hesela teamContact the Hesela team. Information from the Hesela team.
Project
Citing and reusing HeselaCiting and reusing Hesela. Information from the Hesela team.
Project
Privacy and local featuresPrivacy and local features. Information from the Hesela team.
Project
Observatory updatesObservatory updates. Information from the Hesela team.
Technology
Serial Attached SCSISerial Attached SCSI is a serial storage interconnect with distinct protocols for SCSI traffic, SATA tunneling and domain management.
Technology
Single-Level Cell NANDSLC NAND stores one bit per cell using two distinguishable threshold-voltage states; native SLC media and single-bit operation on multi-bit-capable NAND must be distinguished.
Technology
Multi-Level Cell NANDIn this card, MLC means NAND storing two bits per cell using four distinguishable threshold-voltage states; the broader phrase multi-level cell also includes TLC and QLC.
Technology
Triple-Level Cell NANDTLC NAND stores three bits per cell using eight distinguishable threshold-voltage states.
Technology
Quad-Level Cell NANDQLC NAND stores four bits per cell using sixteen distinguishable threshold-voltage states.
Technology
Helium-Filled Hard Disk DriveA helium-filled HDD uses a sealed helium atmosphere around its rotating disks and heads to reduce aerodynamic loading; it is an enclosure technology, not a magnetic recording method.
Technology
Dual-Actuator Hard Disk DriveA dual-actuator HDD uses two independently positioning head assemblies within one physical drive to service different data regions concurrently.
Technology
Linear Tape-OpenLinear Tape-Open is a licensed, multi-vendor magnetic-tape format for removable storage, with generation-specific media capacity and drive compatibility.
Technology
Solid-State DriveA solid-state drive is a storage device that retains data in nonvolatile semiconductor memory without moving recording media; most SSDs use NAND flash, but SSD does not specify an interface or a form factor.
Technology
Conventional Magnetic RecordingCMR lays down magnetic tracks side by side without overlap. Modern drives still use perpendicular magnetic recording under the hood; vendors label the product behavior “CMR” to distinguish it from shingled (SMR) layouts.
Technology
Shingled Magnetic RecordingSMR increases HDD areal density by writing new tracks partially overlapping previous ones—like roof shingles—so each pass narrows the writable track width. Reads stay random-access, but rewriting a sector often requires reading and rewriting entire shingled bands, so vendors expose SMR through drive-managed firmware or host-visible zoning (ZAC/ZBC).
Technology
Perpendicular Magnetic RecordingPMR records magnetization perpendicular to the disk surface; it specifies orientation, not whether tracks overlap or the writer uses heat.
Technology
Heat-Assisted Magnetic RecordingHAMR uses localized optical heating to let a magnetic write head record high-anisotropy media, which regain thermal stability as they cool.
Technology
Nearline Hard Disk DriveA nearline HDD is a vendor category of capacity-oriented enterprise hard disk drives commonly used for bulk online storage, distinct from nearline as a storage-availability class.
Technology
Microwave-Assisted Magnetic RecordingMAMR denotes microwave-assisted magnetic recording, but Toshiba's FC-MAMR product name identifies flux-control assistance rather than requiring microwave resonance in the recording medium.
Technology
NVM ExpressNVMe defines storage commands and transport models for non-volatile memory. Its PCIe path separates submission and completion queues from data buffers; NVMe over Fabrics extends access over network transports. NVMe is a protocol family, not a connector, drive shape or promise of a particular latency.
Technology
Hard Disk DriveA hard disk drive stores bits on spinning platters coated with magnetic material, read and written by heads on a moving actuator. Decades of mechanical, interface, and recording-technology layers—CMR, SMR, HAMR, helium fill, dual actuators—now sit behind the same logical block abstraction exposed over SATA, SAS, or USB bridges.
Technology
Floppy DiskThe floppy disk is a removable flexible magnetic disk sealed in a jacket, first shipped by IBM in 1971 as the read-only 8-inch 23FD diskette drive (code name Minnow) that held about 80 KB, roughly 3,000 punched cards, and was built to load microcode into IBM mainframe controllers.
Technology
GMR Spin-Valve Read HeadA GMR spin-valve head is a hard-disk read sensor built from two magnetic layers separated by a thin non-magnetic spacer, with one layer pinned by an antiferromagnet so that the other rotates in the field of a bit and changes the sensor's electrical resistance; IBM shipped the first one in the 16.8 GB Deskstar 16GP, announced in November 1997 and approved for shipment on 24 December 1997.
Technology
Removable Cartridge DiskA removable cartridge disk is a magnetic disk drive whose recording disk travels in a cartridge that the user swaps in and out, and the 1982-1999 generation split into two designs: flexible media held next to the head by an air film (Iomega Bernoulli Box, 1982; Zip, shipping March 1995) and rigid hard-disk cartridges (SyQuest SQ306, first shipped 8 August 1982; Iomega Jaz, December 1995).
Technology
Magneto-Optical Disc and MiniDiscA magneto-optical (MO) disc is a rewritable disc on which a focused laser heats a spot of a perpendicularly magnetised film until a small applied magnetic field can reverse it, and on which the same laser later reads the bit through the magneto-optic Kerr effect; the technology was demonstrated in 1967, sold as 5.25-inch computer drives from 1988, and was also the recordable medium of the Sony MiniDisc (1992-2013).
Technology
Magnetic Drum and Core Memory (pre-RAMAC storage)Before the IBM RAMAC disk drive of 1956, computers kept programs and data on magnetic drums (a rotating cylinder with a fixed head for each track, first built in the mid-1940s and delivered in a production computer in 1950) and, from 1953, in magnetic core memory (a grid of ferrite rings giving random access to every bit), and the two technologies split a job that disk drives later took over in part.
Technology
Longitudinal to Perpendicular Recording Transition (1975-2010)Hard-drive makers moved from longitudinal to perpendicular recording between December 2004 (Toshiba's first announcement) and about 2010 because thinner longitudinal media were running into a thermal-stability limit, a change that rested on Shun-ichi Iwasaki's work at Tohoku University from the mid-1970s.
Technology
PRML Read Channel (Partial-Response Maximum-Likelihood, 1970-2000)PRML is a way of reading a hard drive that, instead of finding each magnetic peak on its own, equalizes the weak readback signal to a known partial-response shape and uses the Viterbi algorithm to pick the most likely bit sequence; IBM shipped the first disk drive with it, the 0681, in 1990.
Technology
Magnetic Bubble Memory (1967-1986)Magnetic bubble memory stored each bit as the presence or absence of a tiny magnetic domain (a bubble) in a thin garnet film, moved around fixed loops by a rotating magnetic field, so it kept data without power and had no moving parts; it was invented at Bell Labs in the late 1960s, sold by Texas Instruments from 1977 and Intel from 1979, and lost the market in the early 1980s.
Technology
Compact Cassette and DAT as Data Media (1963-2009)The Philips Compact Cassette (1963) became a widely used data medium for home computers once the 1975 Kansas City standard defined how to record bits as audio tones, and the 3.81 mm tape of the cassette lineage returned in the late 1980s as Digital Audio Tape (DAT), whose rotating-head recording was adapted by HP and Sony into the Digital Data Storage (DDS) backup format of 1989.
Technology
Holographic Data Storage (1963-2012)Holographic data storage records whole pages of bits at once as optical interference patterns inside the thickness of a photosensitive medium rather than as marks on a surface, an idea analysed in theory in 1963, developed in research programmes through the 1990s, and taken to prototype drives and an Ecma standard (ECMA-377, 2007) before the companies involved stopped trading.
Technology
Optical Disc Lineage: CD, CD-ROM, DVD, Blu-ray and the HD DVD Format War (1979-2008)The mainstream optical disc lineage is a sequence of 12 cm discs in which each generation kept the disc size and cut the laser wavelength and track pitch (CD at 1982, DVD unified in 1995 and standardised in 1997, Blu-ray announced in 2002), with two format disputes along the way: SD versus MMCD before DVD, and HD DVD versus Blu-ray before the 2008 withdrawal of HD DVD.
Technology
SCSI and ATA Disk Interface History: SASI, SCSI, IDE/ATA, Serial ATA and SAS (1979-2009)Two interface families put the disk controller inside the drive and defined a standard way for a host to talk to it: SCSI, which grew out of Shugart's SASI and became ANSI X3.131-1986, and ATA (IDE), which Compaq, Western Digital and Control Data's Imprimis division developed from 1986 and ANSI standardised as X3.221 in 1994; both later moved from parallel cables to serial links, as Serial ATA (specification 1.0 in 2001) and Serial Attached SCSI (INCITS 376, approved in November 2003).
Technology
Early Flash Memory and the First SSDs: Floating Gate, NOR and NAND, RAM Disks, SunDisk, CompactFlash, Fusion-io and Intel X25-M (1967-2008)Flash storage grew out of the floating-gate memory cell that Kahng and Sze described at Bell Labs in 1967, was turned into one-transistor 'flash' erase by Fujio Masuoka at Toshiba (NOR cell shown at IEDM in December 1984, NAND cell shown at IEDM in 1987 or 1988 depending on the source), and reached disk-like products through SunDisk's flash disks of 1991 to 1994, the CompactFlash card announced in December 1994, and the PCIe and SATA drives of 2007 and 2008, after a separate line of RAM-based solid-state disks had been sold since 1976.
Technology
IBM 3340 Winchester: Removable Heads and Disks (1973)The IBM 3340 Direct Access Storage Facility, announced in 1973 and first shipped in November 1973 according to the sources read, used a lightly loaded ferrite slider that rested on a lubricated disk in a dedicated landing zone when stopped and flew on an air bearing when spinning, packaged with the disks and head carriage in a removable 3348 Data Module of 35 or 70 megabytes; IBM's internal code name 'Winchester' came from an early 30-megabyte-plus-30-megabyte specification, and the name later became the common label for the head-and-disk technology that followed.
Technology
Voice Coil Actuators in Hard Disk Drives: From the IBM 2310 and 3330 to Rotary Arms (1965-1990s)A voice coil actuator moves a disk drive's heads with a coil that sits in a fixed magnetic field and produces a force proportional to the current in it, like a loudspeaker; IBM is credited by the sources read with the first one in a disk drive in 1965 (the 2310 cartridge drive), with using it inside the first closed-loop track-following servo in the 3330 in 1971, and with a rotary version from its British laboratory in the mid-1970s that later became the standard arm geometry.
Technology
Wear Leveling in Flash Storage: Dynamic and Static Methods from Early Patents to JFFS2 and Static Leveling (1992-2007)Wear leveling is the practice of steering flash erases so that no erase block reaches its erase-cycle limit long before the others; the sources read show it written down in patents filed in 1992 and 1993, split into dynamic leveling (spreading new writes over free blocks) and static leveling (also moving data that is never rewritten), and made a named mechanism of its own for static data in a 2001 M-Systems patent filing and a 2007 design paper.
Technology
Filesystem Journaling: From Write-Ahead Logging and Cedar to JFS, VxFS, XFS and ext3 (1977-2001)Filesystem journaling is the practice of recording a file system's pending metadata changes in a log that reaches disk before the changes reach their permanent place, so that after a crash the file system is repaired by replaying that log instead of scanning the whole disk; the sources read trace it from the write-ahead log rule in Jim Gray's 1977 database notes through Xerox's Cedar file system (1987), IBM's JFS (a 1990 paper), Transarc's Episode (1992), SGI's XFS (shipping from December 1994) and Linux ext3 (merged in November 2001).
Analysis
3D NAND retention: layer count is not a reliability ratingSeparate NAND architecture, dwell, thermal annealing and read conditions before interpreting raw error rates or claims of restored SSD endurance.
Analysis
AFR is a rate, not a one-year failure probabilityWhy exposure, zero-failure probability bounds, survival curves and censoring assumptions matter when interpreting drive reliability, with reproducible synthetic examples.
Analysis
Atomic rename is not a durable commitFile contents, directory entries and commit acknowledgements have different persistence boundaries. Linux documentation and two USENIX studies explain what a rename does not guarantee.
Analysis
B-epsilon trees: visible updates, deferred workHow buffered tree updates remain query-visible, why blind upserts differ from read-modify-write, and why equal flush counts can hide different completion times.
Analysis
Missing SMART ages and the limits of drive-age comparisonsA full Q4 2025 raw-data audit finds 18 TB drives in a mislabeled capacity group and shows why excluding 106 missing-age drive-days also excludes 19 failures.
Analysis
Backup verification is not a restore testSeparate backup completion, integrity, freshness and usable recovery, with reproducible SQLite and rsync experiments and explicit limits.
Analysis
Bloom filters: optimize the lookup, not each filterLSM lookup costs, filter retention and counting limits, with reproducible allocation, deletion and memory examples grounded in primary sources.
Analysis
Btrfs tree logs: why a read-only mount can still replay writesSeparate Btrfs fsync logging, transaction commit, read-only mount recovery and destructive log clearing, with a reproducible Linux 6.15/6.16 option audit.
Analysis
Why a valid checksum can still return the wrong dataChecksums, identity, freshness, Linux verity and disk encryption: what successful verification does and does not prove, with reproducible examples.
Analysis
Azure disk-error prediction caught 36.5% of faulty disks at a 0.1% false-positive rate, and random cross-validation said 91.6%In Xu et al. (USENIX ATC 2018), Microsoft's disk-error predictor, CDEF, found 36.50% of faulty disks on one test set when it was allowed to wrongly flag only 0.1% of healthy disks (29.67% to 41.09% across three test sets), with about 10,000 healthy disks per 3 faulty ones. Scored with a random split, the same task gave 91.64%, which is why the authors insist on testing forward in time. Adding system-level signals such as OS events to SMART raised the average catch rate at that false-positive rate from 27.6% to 30.3%, and to 35.8% with feature selection. In production at Azure the authors report about 63,000 fewer minutes of VM downtime a month. The data are one cloud system in one month, and labels come from engineers' root-cause analysis of service problems.
Analysis
Content-defined chunking: boundaries are not identityReproducible FastCDC examples show how file framing, parameter changes and terminal chunks alter measured reuse, even when file contents remain unchanged.
Analysis
Crash-consistency tests: the oracle is part of the resultWhat ALICE, CrashMonkey/ACE, SQLite and Ananke actually test: fault boundaries, separate recovery outcomes and an executable correctness-oracle example.
Analysis
Datacenter failure tickets are not failed-device countsA hardware ticket, a failed device and a service outage are different counting units. Review the reported fleet figures, separate response time from repair time, and reproduce why a 120-second failure-burst rule need not limit a burst to 120 seconds.
Analysis
Deduplication ratio does not predict restore costA cold-cache trace separates container rereads from unused fetched bytes, with six reproducible examples and a review of two USENIX papers.
Analysis
Discard is not zeroing: what TRIM, UNMAP and fstrim actually promiseA discard request, zero-filled readback and reclaimed physical space are different observations. Protocol and Linux documentation show how to interpret each without false assurances.
Analysis
In an 18-month Berkeley study of 368 disks, 7 data disks failed against 13 enclosure backplane failures; disks were 90% of parts but about 4% of errorsIn Talagala and Patterson (UC Berkeley, 1999), 18 months of operation of a prototype with 20 PCs and 368 SCSI data disks, 34 components were replaced. Only 7 of the 368 data disks (1.9%) failed, the lowest percentage of any failing component, against 13 of 46 disk enclosures (28.3%, backplane faults) and 6 of 24 IDE system disks (25.0%). Disks were about 90% of the components but only around 4% of 688 logged error instances, while SCSI timeouts and parity errors were 49% (87% without network errors), and no restart was caused by a data disk. Ford et al. (OSDI 2010) later found a disk MTTF of 10 to 50 years against 4.3 months for a node, and Schroeder and Gibson (FAST 2007) found disks were 20% to 50% of hardware replacements, a count not a rate.
Analysis
eMMC, UFS and RPMB: interface, boot and security boundariesHow managed flash differs from raw NAND, why eMMC and UFS are not interchangeable interfaces, and why RPMB authentication is neither encryption nor a backup.
Analysis
Enterprise SSD replacements ran at 0.22% a year across 1.4 million NetApp drives, with firmware the biggest swingIn Maneas et al. (FAST 2020), about 1.4 million SSDs in NetApp enterprise storage systems had an average annual replacement rate (ARR) of 0.22%, with models ranging from 0.07% to nearly 1.2%. That is well below the 4% to 10% of Google's flash drives removed within four years and the 2% to 9% a year the same paper quotes for hard disks, though the definitions of replacement differ. Within the NetApp data, the earliest firmware versions of some models were replaced up to 8 to more than 10 times as often as later ones, and the chance of a second replacement in the same RAID group within a week was 9.39% against 0.0504% in a random week. One third of replacements were predictive and another third were severe SCSI errors. Method limits are on the note.
Analysis
Ext4 journal replay: why old writes must sometimes be skippedJBD2 replay, checksum failure paths and ambiguous log tails, with source-checked recovery boundaries and reproducible counterexamples.
Analysis
F2FS: when a successful fsync is not a recovery promiseA pinned Linux source audit separates F2FS checkpoints, roll-forward recovery and the fsync success path when checkpointing is disabled.
Analysis
Perseus: why slow drives are not always broken drivesPerseus detects drive slowdowns, but shared-path faults can escape its peer model. Review host scheduling, benchmark limits and checked ratio examples.
Analysis
Network is the largest fail-slow hardware type: 29 of 112 occurrences in 101 reportsNetwork is the largest hardware type in Table 3 of Gunawi et al., FAST 2018: 29 of 112 root-cause occurrences, ahead of CPU 25, disk 23, SSD 22, and memory 13. Those 112 occurrences come from 101 fail-slow reports at 12 institutions, incidents reported from 2000 through 2017, and a report can name more than one cause. Device errors account for 40 occurrences and firmware issues for 20. Temperature, power, environment, and configuration sum to 44 of 112 (39.3%), which rounds to the proceedings’ statement that 39% of root causes are external factors, not 39% of the 101 reports.
Analysis
Fast file clones: where the copying cost goesSeparate reflinks, hard links and in-kernel copies; trace deferred costs, Btrfs maintenance, shared-space accounting and FAST 2020's research limits.
Analysis
Filesystem aging: the state SSD warm-up does not describeSeparate filesystem layout history, free-space fragmentation and SSD conditioning, with three USENIX studies and a reproducible allocation counterexample.
Analysis
ZFS and Btrfs checksum counters: coverage and blind spotsChecksum counters expose corrupt reads that device health can miss, but zero errors do not prove integrity or identify which component failed.
Analysis
What fails most often: unreadable data on disks, uncorrectable reads on SSDs, and bus errors on the linkThe most frequent field fault is not a dead drive but data that cannot be read: 3.45% of 1.53 million hard disks developed at least one latent sector error in 32 months, and 20.3–90.5% of Google's flash drives (ten models, first 4 years; 3 for eMLC) had at least one uncorrectable error and 19.1–62.7% a final read error, while 4.2–34.1% of Facebook's SSD platforms reported at least one uncorrectable error. Link faults show up separately as CRC counts (about 2% of Google's disks), and the public counters miss a large share of failed drives: over 56% of failed drives in the Google study and 23.3% in Backblaze's 2016 log showed no signal on the SMART attributes each used.
Analysis
Why retrying a failed fsync does not prove durabilityWhy a successful fsync retry can leave stale data: historical research, Linux close errors, POSIX portability, synchronization boundaries and reproducible descriptor-lifetime observations.
Analysis
CMR is not refresh-free: adjacent-track interference in HDDsRepeated HDD writes can trigger protective refreshes even with CMR. Separate write-induced ATI, read-channel interference and SMR band rewrites before diagnosing latency.
Analysis
HDD workload ratings: count reads, check the clockAn HDD workload rating is not SSD TBW or a failure countdown. Power-on hours, read traffic and maintenance scans change what the annualized number means.
Analysis
HDD mechanical faults: evidence and diagnostic limitsShock models, vibration tests and vendor counters reveal different parts of HDD mechanics. They do not provide a universal damage threshold or a failure forecast.
Analysis
HDD write verification: completion, persistence and comparisonRead-after-write verification, IRAW and SCSI VERIFY answer different questions from flush or FUA. Learn what a successful check does and does not establish.
Analysis
io_uring: completion is not a durable commitio_uring write ordering, protection information, cancellation CQEs and linked timeouts: what each result proves, and what still needs synchronization.
Analysis
iSCSI identity, sessions and recovery: what a second portal does not proveSeparate iSCSI names, portals, sessions, command ordering and recovery levels, with a source-checked distinction between projected and measured performance.
Analysis
Key-value separation: the cleaning bill moves elsewhereWiscKey, HashKV and BlobDB separate value movement from key sorting. A reproducible byte model shows when value-log cleaning can erase the saving.
Analysis
LDPC in NAND: the read cost of confidenceHow soft information is acquired, why decoder structure changes the result, and which error-rate denominators an SSD reliability claim must disclose.
Analysis
Linux atomic writes: untorn does not mean durableAtomic writes, durable completion and powersafe overwrite protect different boundaries. Check Linux request geometry and SQLite's outside-range assumption.
Analysis
LMDB readers: a stable snapshot can exhaust a fixed mapA controlled LMDB experiment separates reader lifetime, reusable pages and map capacity: why a live reader can stop writes without holding the writer mutex.
Analysis
Local repair is not whole-node repairA reproducible LRC comparison separates data-fragment reads, parity repair and whole-node accounting without equating read savings with durability.
Analysis
LSM tombstones: deleted is not yet reclaimedSeparate delete visibility, crash durability and space reclamation: snapshots, Lethe's delete-aware compaction and RocksDB's range-tombstone safeguards.
Analysis
Magnetic retention: why 60 kBT is not an expiry dateA reproducible two-state model separates first reversal, final-state error and magnetization decay, and shows why a mean energy barrier cannot predict retention.
Analysis
Disk failure prediction: signals, scores and alert costsLu et al.'s fleet study tested SMART, performance and location signals. Interpret its scores alongside explicit alert denominators, prevalence and validation limits.
Analysis
Memory-mapped files: visibility, size and synchronizationSeven reproducible Linux checks distinguish mapped visibility, file size, partial-page tails, SIGBUS and sync argument errors from power-loss durability.
Analysis
Disk replacement rates are not disk lifetimesField replacement logs count operational decisions, not verified component lifetimes. Drive age, fleet event gaps and repeated-event rates answer different reliability questions.
Analysis
NAND copyback: faster relocation is not fewer writesWhy on-chip page relocation can bypass controller ECC, why destination placement matters, and why lower NAND-channel traffic is not lower write amplification.
Analysis
BCH, LDPC and the RBER aggregation trapA drive-wide raw error rate cannot reveal the hardest codeword. How to compare BCH and LDPC evidence without confusing fleet telemetry with decoder limits.
Analysis
NAND erase blocks: geometry is not write amplificationMore pages per erase block can increase work per collection, but the live-data fraction, mapping policy and workload determine the write cost. Separate historical chip parameters, simulated SSD results and a reproducible accounting example.
Analysis
NAND paired pages: why a later write can damage earlier dataTwo NAND pages can share cells. Distinguish interrupted programming, neighbor interference and the protection promised by an SSD.
Analysis
NAND read-retry: when a successful SSD read takes longerWhy retry counts do not determine SSD read latency: chip evidence, pipelined recovery and reproducible synthetic stage-timing examples.
Analysis
Why deleted NFS files become .nfs filesSilly rename, open-file preservation and a misleading Linux comment: trace NFS deletion from the 1985 paper to a pinned implementation and RFC erratum.
Analysis
NFS stable writes: what COMMIT, flush and FUA actually promiseNFSv3 stability, COMMIT verifiers and Linux flush/FUA: distinguish durable writes from cache visibility, with bounded NFSv4 delegation comparisons.
Analysis
NVMe over Fabrics: transports, discovery and security boundariesDistinguish NVMe/TCP, NVMe/RDMA and NVMe/FC from discovery, path selection and security, without treating a transport label as a performance guarantee.
Analysis
Fail-slow NVMe SSDs: what SMART and heartbeats missSeparate fleet counts from model averages, review uncertain follow-up dates, and test how a live heartbeat can miss stalled storage work.
Analysis
NVMe FDP: placement handles are not physical addressesHow reclaim units, handles and placement identifiers fit together, why FDP differs from ZNS, and what a credible write-amplification comparison must measure.
Analysis
NVMe health log: warning bits, wear estimates and counter limitsRead NVMe health counters with the right units and version: wear is not failure probability, host writes are not NAND writes, and warnings are not a fault history.
Analysis
NVMe multipath: ANA access states and Linux path policiesSeparate NVMe namespace identity from ANA access states: NSID scope, identifier lifetime, Linux path policies and controller-level queue accounting.
Analysis
O_DIRECT alignment: query the file, not a fixed block sizeQuery O_DIRECT per-file alignment and distinguish cache hints, prefetch, NOWAIT and mincore residency from actual I/O and durable writes.
Analysis
Object ETags: checksums and conditional writes are differentS3 ETags, full-object and composite checksums, version IDs and write preconditions: what each validates, and how to avoid checking download metadata instead of bytes.
Analysis
Optical disc lifetime: error thresholds, percentiles and uncertaintyOptical-disc lifetime is not a warranty: CD/DVD error units, survival estimates, Blu-ray HTL/LTH, and a source-level check of M-DISC longevity claims.
Analysis
Optical disc rot: what public ageing studies measured, which error counters (BLER, PI sum 8) warn first, and what they cannot predictRecordable discs fail mainly because the organic dye layer breaks down or, on discs with a silver reflective layer, the metal corrodes, and the public tell-tale is a rising correctable-error counter before data is lost: block error rate (BLER, counted at the first CD decoder) against a specified maximum of 220 per second on CD, and parity-inner errors summed over eight blocks (PI sum 8) against a maximum of 280 on DVD. In the NIST and Library of Congress study of discs bought in 2005, all 7 CD-R products reached an estimated life of more than 30 years at 25 C and 50% relative humidity (5 of 7 more than 45 years), while the 15 DVD products spread from under 15 years (2 products) to more than 45 years (7 products). Canada's conservation institute ranks a gold-layer phthalocyanine CD-R above 100 years and a dye or non-dye single-layer Blu-ray recordable at 5 to 10 years, and says discs recorded with poor technique can fail in as little as 2 to 10 years. These are accelerated-ageing estimates of temperature and humidity effects only, for disc products of 2005 or earlier, so they rank media and set expectations but are not a failure rate for any disc in use today.
Analysis
Parity declustering: less load per disk, not fewer readsAn executable eight-disk example separates repair-read volume, survivor load and stripe width, with evidence from ASPLOS, Panasas and OpenZFS dRAID.
Analysis
Phi failure detectors: suspicion is not a failure probabilityWhat a phi score measures, why Cassandra's score differs from the original model, and why suspecting a replica does not fence it. Includes reproducible synthetic examples.
Analysis
Persistent memory: DAX is not a durable commitADR, eADR and MAP_SYNC protect different boundaries. A source-linked review and executable crash-state example separate addressability, visibility, persistence and atomicity.
Analysis
Two clocks for one GitLab.com loss: 00:00 UTC and 23:30 UTC, at least 5,000 projects in the postmortem, 5,037 in the logOn GitLab.com’s one primary and one hot-standby secondary, the 10 February 2017 postmortem prints two ends for database rows lost on 31 January 2017: the introduction says 17:20 and 00:00 UTC on that date, and the data-loss section says 17:20–23:30 UTC. It says the exact loss is hard to estimate: at least 5,000 projects, 5,000 comments, and roughly 700 users. The incident log archived at 2017-02-02 03:47:19 UTC prints ±6 hours, 5,037 projects, ±4,979 comments, and 707 users that were hard to confirm from Kibana. Those figures are vendor claims, not a census of objects that stayed gone. The same postmortem says projects restored from remaining Git data came back only in basic form, without issues or merge requests.
Analysis
Protection information: when success skips the checksumA pinned Linux verifier test separates PI escape tags, guard checks and 32-bit reference aliases. Sixteen cases show why accepted does not always mean checked.
Analysis
RAID rebuild risk: read-error models, field evidence and resilver boundariesA datasheet error-rate limit is not a measured rebuild-failure probability. Under an illustrative independent-error model, reading five 12 TB survivors at 1 error per 10^14 bits gives 99.2% for at least one read error; five 20 TB survivors at 1 per 10^15 bits give 55.1%. Those are different read volumes, 60 TB and 100 TB, and neither result estimates the chance of losing an entire array. Rebuild, resilver, spare activation and checksum verification are separate recovery milestones.
Analysis
RAID write hole: why a bitmap is not a write journalA bitmap tracks dirty regions; PPL repairs a narrower parity hazard; a journal preserves replay data. A reproducible XOR example separates these guarantees.
Analysis
RAID write penalty is not a speed ratioRead-modify-write, reconstruct-write and full-stripe accounting: why four or six member operations do not mean one-quarter or one-sixth of full-stripe speed.
Analysis
Replacing disks at 200 reallocated sectors removed 88% of triple-disk RAID failures at one vendorIn Ma et al. (FAST 2015), about 1 million SATA disks in backup systems from one storage vendor showed that the count of reallocated sectors (RS) correlates strongly with whole-disk failure. Replacing a disk once its count passed 200 eliminated about 88% of the RAID failures caused by three-disk errors, which were 80% of all RAID failures, or about 70% of all disk-related incidents. The same paper says the signal is incomplete: in simulation, a threshold below 200 caught 52% to 70% of impending whole-disk failures, with 0.8% to 4.5% false positives. Google's FAST 2007 data and Backblaze's 2016 SMART tally point the same way on reallocated sectors, and both also show failed drives with no warning.
Analysis
RAIDZ expansion: why old blocks keep their parity costReflow spreads old blocks across more disks without changing their data-to-parity ratio. A reproducible model separates retained parity overhead, reported space and snapshot-aware rewriting.
Analysis
Reed-Solomon recovery needs more than a fragment countExact GF(7) examples separate MDS recovery, missing fragments and silent corruption, showing why even a unique decoded answer can be wrong.
Analysis
Replica repair: what has actually converged?Replica repair coverage, quorum overlap and set reconciliation: why matching keys, successful responses and compact summaries do not prove identical durable state.
Analysis
Replication acknowledgements: received, durable, appliedCompare replication acknowledgements, WAL retention and logical failover readiness; distinguish durable writes, replay and missing or unusable slots.
Analysis
RocksDB: a WAL sync is not a memtable flushRocksDB WAL sync, memtable flush, write stalls, read snapshots, checkpoints and backups have distinct recovery and retention contracts.
Analysis
Eleven nines: what a durability model does not proveA durability target is not a measured loss rate. Recomputing a historical 20-shard example gives about 1.06e-11 per year with a Poisson event model and 7.72e-12 with a distinct-shard binomial model. The difference is a modeling choice, not evidence that one cloud provider is safer.
Analysis
SATA and SAS link errors: what counters can and cannot diagnoseSATA error flags and SAS PHY counters identify observations in the I/O path, not the component that must be replaced. Preserve endpoint identity, timestamps and reset history before comparing counts. Historical field studies show why a disk-only view is incomplete, but their event shares are not modern SAS failure rates.
Analysis
Disk scrubbing: detection time is not a durability guaranteeHow scrub coverage and irregular inspection intervals limit detection evidence, with exact reproducible examples of waiting-time bias.
Analysis
Media error or link error? What SCSI sense codes and Linux ATA log lines can and cannot tell apartATA registers, Linux's error mask and SCSI sense data describe different layers. They can distinguish a reported media error from a transfer error, but do not uniquely identify the failed component. Recovery thresholds produce conditional verdicts, not guaranteed actions: the audited libata path does not force a SATA ATA disk into PIO. A reproducible comparison also shows why decoding must be tied to a kernel revision.
Analysis
Sector-error prediction: what adaptive scrubbing gainsA 2017 simulation shortened error-detection time. That is not a measured reduction in data loss, and its accelerated-scrub budget is not the false-positive rate.
Analysis
512e, 4Kn and alignment: geometry is not durabilitySeparate logical and physical sectors, partition starts and individual writes. Four reproducible examples show why aligned partitions do not guarantee whole-sector I/O.
Analysis
SIEVE cache eviction: one bit is not scan resistanceExplain SIEVE versus CLOCK and LRU, replay cache traces and FIFO capacity anomalies, and separate miss counts from storage performance claims.
Analysis
0.86% of nearline disks and 0.065% of enterprise disks developed a checksum mismatch in 41 monthsIn Bairavasundaram et al. (FAST 2008), 3,088 of about 358,000 nearline disks (0.86%) and 767 of 1.17 million enterprise-class disks (0.065%) developed at least one silent checksum mismatch over 41 months, in field logs covering 1.53 million disks. That is about 400,000 mismatched blocks in all, but the burden is lopsided: the median affected disk had 3 mismatches, the mean was 104, and the worst disk had 33,000. The paper's rates are per disk and come from one vendor's support logs, so they do not say how often a file is corrupted. An independent 2007 CERN report found 22 mismatching files among 33,700 checked, about 1 in 1,500, using a different method and a different population.
Analysis
Sleeping disks: one readable block is not a recoverable arrayAn exhaustive check of two historical XOR codes separates serving a read without spin-up from recovering every data symbol. Includes code, all 512 availability states and explicit limits.
Analysis
Over 56% of failed drives had no count on the four strong SMART signalsOver 56% of failed drives in the Google production population of more than 100,000 consumer-grade serial and parallel ATA drives (December 2005–August 2006) had no count in any of the four strong SMART signals (scan errors, reallocation count, offline reallocation, and probational count), so models based only on those signals can never predict more than half of the failed drives.
Analysis
SMART zeros, missing attributes and failure-day selectionA complete Q4 2025 raw-data audit separates 66 failed drives with five measured zeros from 170 with partial zero-only readings, and explains why complete-case filtering changes the manufacturer mix.
Analysis
SMART replacement prediction: recall, F-score and random splitsBotezatu et al. report 98% Seagate recall; their Hitachi table gives 79%, while the prose says 81%. These random-split results are not a prospective deployment estimate.
Analysis
What smartctl and smartd can and cannot tell you about a failing driveA successful smartctl process is not a complete health measurement. ATA exit bits distinguish command problems, threshold warnings and logged errors; PASSED is a reported check result, not a guarantee against failure. This guide separates those signals, explains smartd alert prerequisites and preserves unknown readings in tested collector examples.
Analysis
SMB handles and leases: reconnect is not write durabilityDurable and persistent SMB handles, caching leases and write-through protect different boundaries. Learn what to verify after a disconnect or failover.
Analysis
SMR stalls, cache limits and the errors SMART can missAn SMR performance stall and a failed write are different observations. Research explains how internal cleaning can delay work; historical WD40EFAX reports document command errors despite a passing SMART health result. Neither establishes that cache exhaustion caused every reported error, nor that SMR has a higher fleet failure rate.
Analysis
Snapshots and backups: which failures can you recover from?Separate snapshot consistency, independent recovery copies and RPO/RTO targets, with source-backed OpenZFS, PostgreSQL and VSS examples.
Analysis
Soft updates: consistent metadata without a full journalWhy write ordering can leave reclaimable space instead of unsafe pointers, and why background fsck and metadata consistency do not prove application durability.
Analysis
Sparse files, preallocation and thin-pool capacityFile size, allocated blocks and thin-pool headroom are different measurements. Learn what preallocation, hole punching and zero-filled reads actually establish.
Analysis
SQLite WAL checkpoint starvation: success is not completionMeasured SQLite WAL checkpoints and stale-snapshot retries: why restarting a transaction can still overwrite an update when the application reuses old values.
Analysis
Correlated SSD failures: what the Alibaba measurements countHan et al. (FAST 2021) report that 12.9% of failures were intra-node and 18.3% intra-rack at a 30-minute grouping threshold. These are shares of recorded failures, not percentages of all installed drives. Reading the analysis code also separates a group-size statistic from a prediction of the next drive failure.
Analysis
38% of failed datacenter SSDs showed none of the four SMART symptoms; the ones that did failed 3 to 20 times as oftenIn Narayanan et al. (SYSTOR 2016), a study of over half a million SSDs in Microsoft datacenters over nearly 3 years, 62% of devices that fail-stopped had shown at least one of four SMART symptoms (uncorrectable or CRC data errors, sector reallocations, program or erase failures, and SATA downshifts) and 38% had shown none. Devices with a symptom failed 3 to 20 times as often as devices without one, with data errors the strongest at up to 20 times. Of the models whose failure rate could be compared with vendor figures, two consumer models exceeded the published 0.61% to 0.73% annual failure rate. A multi-factor classifier reached 87% precision and 71% recall, but it was scored with 5-fold cross-validation on one operator's data. Maneas et al. (FAST 2020) and Backblaze (2016) show the same pattern in other fleets: symptoms raise risk and a large share of failures give no warning.
Analysis
SSD mapping caches: why DRAM size is not a speed ratingSeparate SSD maps from data buffers, explain cache admission and HMB, and reproduce memory, scan and request-versus-byte hit examples.
Analysis
SSD over-provisioning: the denominator changes the answerConvert SSD reserve percentages correctly, reproduce a uniform-write amplification model, and see why cleaning policy and workload limit its predictions.
Analysis
What an unexpected power cut does to SSDs, and why power-loss protection is hard to check from outsideHistorical power-fault tests exposed SSD data and ordering failures, including on devices labelled with PLP. Those outcomes do not identify a failed capacitor or establish a current-product failure rate.
Analysis
SSD firmware-hour failures: model, revision and runtime matterA healthy wear indicator does not rule out a firmware-hour defect. Vendor advisories describe separate 32,768-, 40,000- and 28,224-hour issues with different affected models and recovery outcomes. Match the exact drive and firmware, then check fresh runtime evidence.
Analysis
34.4% of RASR failures are not the SSD: 20.5% human mistakes, 13.9% cables, 31.2% labeled Failed DeviceIn Xu et al., USENIX ATC 2019, 34.4% of Reported As “SSD-Related” (RASR) failures are not caused by the SSD device. That 34.4% is human mistakes (20.5%) plus faulty cables (13.9%), inferred from which repair worked. It is not the complement of a measured device failure: Table 11 labels 31.2% Failed Device because replacing the SSD is the last resort, 11.9% Transient, and 22.5% Undetermined (FSCK 16.5% plus Data Check 6.0%). The paper prints 20.5 and 34.4. It does not print 22.5 or the addition 20.5 + 13.9.
Analysis
SSD read reclaim: why read-only workloads can cause writesSeparate read disturb, read retry and data relocation; compare device measurements with simulations, and handle zero-host-write intervals without inventing a WAF.
Analysis
SSD sanitization: why TRIM and a successful command are not enoughFile deletion, deallocation and sanitization establish different things. A FAST study, NIST SP 800-88r2 and NVMe status semantics explain what evidence to collect before an SSD leaves your control.
Analysis
SSD steady state is not a timerWhy SSD warm-up duration is not proof of steady state: source review, two independent stability checks and six reproducible synthetic counterexamples.
Analysis
SSD thermal throttling: temperature and NVMe countersA hot SSD reading, a thermal-management event and a drive failure are different observations. Historical fleet studies show platform-dependent temperature associations, not a universal failure threshold. NVMe exposes distinct temperature and action counters; their units, capabilities and specification revision determine what a reading can establish.
Analysis
SSD wear indicators: estimates, failure evidence and NVMe scopePercentage Used estimates consumed endurance; it is not a failure probability. Available Spare measures a different quantity, and a read-only warning is not a promise of continued data access. Historical SATA failures and Google's field study illustrate these limits, but neither calibrates modern NVMe warning coverage. Keep device identity, log identifier and counter scope with every observation.
Analysis
Google measured a disk MTTF of 10 to 50 years but a node MTTF of 4.3 months; 37% of node failures came in burstsIn Ford et al. (OSDI 2010), one year of data from tens of Google storage cells of 1000 to 7000 nodes each, the mean time to failure was 10 to 50 years for a disk, 10.2 years for a rack, and 4.3 months for a node, so node failures, not disk failures, drove availability. 37% of failures were part of a burst of at least 2 nodes. In the authors' model, a 10% cut in the disk failure rate raised stripe availability by less than 1.5%, while a 10% cut in the node failure rate raised data availability by 18%. Maneas et al. (FAST 2020, NetApp SSDs) and Schroeder and Gibson (FAST 2007, HPC1 disks) also found strong clustering of drive replacements in time, so a failure rate alone does not describe risk.
Analysis
Storage consistency: ordering is not a transaction or a durability promiseLinearizability, transactions, four session guarantees and compare-and-swap: identify the scope of a storage guarantee before relying on it for correctness.
Analysis
Storage fencing: why a lost heartbeat does not stop writesDelayed I/O, SCSI and NVMe reservations, host identity and fencing tokens explain why path failover alone cannot protect shared storage.
Analysis
What do public storage-incident postmortems show about drives that fail together?Four public postmortems show drives failing together or in bulk because they shared something (a controller, a lot, a firmware), and the reports separate what the logs showed from what the operator only suspects. InfiniCLOUD (October 2026): 6 of 11 disks in a ZFS RAIDZ3 pool sat on one controller; one disk failed at 01:43 JST on 1 October, and a fourth had failed by 19:21 JST on 2 October, 41 h 38 min later, beyond the 3-disk tolerance; the cause of the last three failures is still unknown. Echelon VPS (February 2026): both NVMe drives of one mirror, same manufacturing lot and nearly equal write volume, hit a firmware assertion 4 min apart and took 218 instances offline for 94 min. GitHub (January 2016): a 2 h 6 min outage after a power blip, when over 25% of servers could not see their own drives after rebooting, a known firmware issue. Seagate (January 2009): a firmware event-log bug hung drives at power-up when the log counter was at entry 320 or 320 + n x 256, and the first fix was withdrawn after it disabled some 500 GB drives. None of the four reports publishes the raw logs, and three of the four name no drive or firmware version.
Analysis
Storage latency: when the benchmark stops askingA completion-driven load generator can hide queueing during a stall. A reproducible synthetic example explains coordinated omission, timing boundaries and why p99 values cannot be averaged.
Analysis
Slow RAID hours are not request tail latencySlow-drive hours and request percentiles count different events. Source review and exact examples distinguish fan-out, hedged reads, cancellation work and replica dependence.
Analysis
Storage timeouts: an expired timer is not a cancelled writeDistinguish drive recovery limits, CDL descriptors, host timeouts and multipath queueing; preserve retry identity when write completion is uncertain.
Analysis
Tape shoe-shining: how much a backhitch costs, what speed matching removes, and what the logs do not showWhy tape backhitches interrupt streaming, when filemarks confirm buffered writes, and how host supply and explicit byte units change a buffer-drain estimate.
Analysis
What LTO TapeAlert can tell you about a failing tape, and what it cannotTapeAlert reports conditions, not a cartridge failure rate. Flag meanings depend on whether the target is a drive or a library, and reading the log can clear the evidence. LTO error-rate specifications describe a separate model: they do not establish annual data durability or the health of unread data.
Analysis
Unnamed files: publishing is not replacingA native Linux observation separates O_TMPFILE staging, linkat publication, no-replace rename and atomic exchange from crash durability.
Analysis
USB storage resets: recovery is not a root-cause diagnosisA UAS abort or USB reset identifies a recovery action, not the failed component. Pinned Linux code, a historical incident and SMART documentation separate transport symptoms, compatibility quirks and disk-health evidence.
Analysis
WAL, checkpoints and torn pages: three different recovery guaranteesWAL recovery boundaries: PostgreSQL hint-bit writes, page-image compression and statistics traps, plus InnoDB doublewrite and SQLite commit semantics.
Analysis
XFS delayed logging: which commit is durable?Separate XFS commit from persistence, relogging from deferred recovery, and journal atomicity from online visibility.
Analysis
ZFS ZIL and SLOG: the boundary between logging and persistenceZIL, SLOG and transaction groups protect different boundaries. Pinned OpenZFS code explains indirect records, sync settings and misleading log-byte counters.
Analysis
ZNS resource limits: why closing a zone may not unblock writesOpen and active zone budgets, Linux write plugging, native versus emulated Zone Append, and the limits of ZNS performance comparisons.
Timeline
Storage technology timelineMilestones in magnetic, optical and solid-state storage.