End of a shoot day. The offload is complete, the report shows "verified" next to every file, the copies are on two drives. The card gets formatted for tomorrow.
One question, though: was that verification checksum computed by reading the data from the disk... or from RAM?
The implicit promise
When an offload tool marks a file as "verified", the implicit promise to the person using it is clear: the bytes are physically on the destination media, and they can be read back. That's the whole reason verification exists — bits corrupted in transit, faulty controllers, cables on their last legs, media starting to fail. The classic mechanism is simple: copy the file, read it back from the destination, compare the hashes. If they match, what arrived is identical to what left.
There is, however, an invisible guest in this process: the operating system's cache.
macOS — like every modern system — keeps freshly written pages in memory. It's a valuable optimization: it keeps the system responsive and reduces wear on storage. But it has a side effect worth pausing on. When the tool reads the file back to verify it, moments after writing it, the system can serve that read entirely from RAM, without ever touching the disk. The result is that the comparison happens between what's in memory and... what's in memory.
It's like dictating a text to someone and, to verify they wrote it down in their notebook, asking them to repeat it back out loud. If they have a good memory, they'll repeat it perfectly — but you never checked the notebook.
This verification isn't false: it still catches errors in the in-memory write path, and that's not nothing. But it is vacuous with respect to the promise that matters: it doesn't prove the data can be read back from the physical media. And the difference between the two is something you discover at the worst possible moment — when that drive is the only copy left.
Why nobody talks about it
Cache-served verification has three inconvenient properties: it's faster than the real thing, it produces an identical report, and the user has no way of noticing from the outside. The file is there, the hash matches, the label is green.
Which means there is no market pressure to do the right thing. A tool that verifies from the cache appears faster than one that verifies from the media, at the same declared guarantee. The market, without knowing it, rewards vacuous verification.
It's not bad faith — in most cases it's simply a question that was never asked. The readback "works", the hashes match, the tests pass. You have to go and ask where the system is actually reading from to discover that the question has an uncomfortable answer.
I found it in my own tool
This isn't a theoretical problem, and it isn't a problem "other tools" have. I found it while analyzing the verification engine of evrExpanse — my own software.
It started with a doubt, the kind that sounds like nitpicking: the verification readback happens right after the write — but where does it read from, exactly? I stopped deducing it from the code and went and measured it. The answer was unambiguous: under normal conditions, the readback was being served entirely from the system cache. The report was telling the truth about what it had measured — but what it was measuring wasn't the disk.
There was a second, subtler effect. evrExpanse keeps a counter of files recovered on a second attempt after a verification mismatch. Some time ago, that counter had fired several times on a drive that, shortly after, turned out to be close to failing. Under the old mechanism, that signal measured less than it seemed to: a mismatch could only reveal problems in the in-memory path. Under the new mechanism, the same counter becomes a real indicator of media health — the canary in the coal mine it should have been all along.
The consequence was redesigning the mechanism from scratch, around one non-negotiable principle: verification must read from the physical media, always — and it must be possible to prove that with measurements, not assert it on trust.
It can be fixed, and it costs little
The problem is solvable at the operating system level: mechanisms exist to guarantee that data is persisted to the media before verification begins, and to force the readback to go through the disk rather than through memory.
The hard part isn't knowing that these mechanisms exist — it's that their behavior varies across storage types. What works on an internal volume can behave differently on a network volume or a card, in ways that cannot be inferred from one another. A solution implemented by ear works on one filesystem and fails silently on another — which is exactly the kind of failure this problem teaches you to fear.
Measure, don't assume
While developing the new mechanism, more than one reasonable hypothesis — the kind any experienced developer would sign off on after reading the documentation — turned out to be wrong once measured. In this territory, the system's real behavior cannot be deduced: it has to be measured, configuration by configuration, and you accept what the numbers say even when they contradict intuition. It's why every number in this article comes from a real test, not an estimate.
What it actually costs
And the cost? In the tests conducted for the upcoming evrExpanse 7.1, the overhead of real verification compared to cache-served verification is typically under 3% on SSD destinations. It rises to around 9% when the source is already bandwidth-saturated, and approaches 17% in the most unfavorable scenario: datasets of thousands of very small files. It's only fair to say that too: transparency about the numbers is worth more than a single, well-chosen number.
Put in perspective: for the vast majority of real-world offloads, the difference between a vacuous verification and a real one costs a handful of seconds. Which makes the question unavoidable — if it costs this little, why settle for the version that proves nothing?
The questions to ask your tool
If you use an offload tool — any tool, including mine — these are the three questions worth putting to whoever develops it:
- Does verification read from the physical media or from the system cache? And how do you prove it? — This is the question that separates those who have confronted the problem from those who never asked it. The right answer contains measurements, not adjectives.
- Is the data guaranteed to be persisted to the media before verification begins? — Reading back from the disk isn't enough if, at readback time, the disk hasn't received everything yet. The two guarantees travel together or they're worth nothing.
- Is the declared overhead measured or estimated? On which storage configurations? — Whoever measured can tell you where the cost rises and why it's acceptable. Whoever estimated will give you a single number, and it will be the flattering one.
These are questions that can be answered publicly, with measurements in hand. The upcoming evrExpanse 7.1 release is the product of this work: its technical documentation will state what verification guarantees, what it does not, and its measured cost across storage scenarios.
Because "verified" is not a green label in a report. It's a promise about the contents of a disk. And in this line of work, promises get verified.
