Diagnostics
Reading a Drive That Reports on Itself
A drive that reports nothing wrong is reporting what its own firmware chose to count, in units its own vendor defined.
A storage drive keeps its own ledger, and a tool such as smartmontools is used to read that ledger out of the drive; that description is bench usage, since neither page of the project could be read here. Its entries are called self reported attributes, and the name carries the warning: the drive wrote them, the drive chose what was worth writing, and the drive's maker defined the units they are counted in.
This page is about reading those entries without reading more into them than they carry. It is also, in one section, about what happened when the desk went to read the documentation behind the tool and was asked to prove it was not a bot.
The firmware chose what to count
An attribute is not a measurement the reader makes. It is the drive's account of something its firmware decided to keep track of, expressed on a scale that firmware's manufacturer defined. Two drives from different makers can show the same figure in the same column with no shared meaning between them, because the meaning travels with the vendor's definition and not with the column heading.
A line that has never moved is not a line that has never been exercised. It is a line the firmware has had nothing to write, which is a statement about a counter and only about a counter. A misreading starts in the distance between those two sentences.
What does a clean report actually prove?
A clean report proves that nothing the firmware counts and marks was counted and marked, up to the moment of the read. That sentence is deliberately narrow. It does not say the drive is sound. It says the drive has not reported an unsound one in the vocabulary it owns.
The desk applies the same discipline to memory, where a pass says that those patterns, on those modules, at that speed, produced no detected error during that run, and nothing else. So a machine that crashes under load and a spotless drive report do not contradict each other. The question of what a load test proves is its own, and it has its own page.
Read a counter against its own past
One reading gives a position. Two give a direction, and direction is usually what a diagnosis is short of. The bench habit is to read the report before anything on the machine changes, write down what it says, and read it again after whatever came next, so a line can be read as movement instead of as a verdict.
Nothing in the tool imposes that habit. It is the desk's, and it exists because a single read invites the reader to supply the reference point from memory, and memory supplies the one the reader expects. A recorded earlier read does not.
Before a first read
- Read the report before changing anything on the machine, so the next read has something to be read against.
- Note which drive each read came from, since a machine can hold more than one.
- Put a date beside each read, because a second read is worth the gap between the two.
- Take each read the same way, so a change in the output is a change in the drive and not a change in the method.
Three witnesses that were never going to agree
A drive's report is one of three instruments a bench reaches for, and the three do not measure the same thing. Setting them side by side is what stops any one of them from being promoted past what it can say.
| Source | What it speaks about | A clean result means | A flagged result means |
|---|---|---|---|
| The drive's own report | What its firmware counts, in units its vendor defined | Nothing was counted and marked, up to the read | The firmware marked something; the meaning sits in the vendor's definition |
| A run under load | The whole machine, while it is made to work | Those patterns, at those speeds, produced no detected error in that run | Something failed under that load, in that run; where is a separate question |
| A sensor read | A condition, at the instant of the read | The condition sat there at that instant, and says nothing about the hour before | The instant deserves a second read, not a conclusion |
The report is the cheapest of the three to take and the narrowest in what it covers. A run under load is the slowest and the only one that speaks about the machine as a whole. A sensor read sits between them and is the easiest to mistake for a verdict, because a single number looks like a conclusion.
What did the project's own pages return?
The definitions a reader eventually needs belong to the project, so the desk went to read them before writing this page. Both the front page of the project's site and its wiki FAQ answered with the same screen, headed "Making sure you're not a bot!", followed by a request to wait a moment while the security of the connection is checked. Nothing else came back, and the description those pages publish came back empty.
That is a fact about one visit, not about the project, and it earns its place here for a second reason: it is the trap this page warns about, pointed at the reader instead of at the drive. A gate that returns one line does not say what stands behind it. The definitions sit at the project's own site, and this page declines to quote a threshold or a meaning it did not read there.
Where this goes wrong
The first error is promotion. A reader takes one clean report and calls the drive sound, or takes one flagged line and calls it the cause of a crash nobody reproduced. Both moves hand the report more authority than its own vocabulary carries, and both close the investigation at the point where it should have widened.
The second is borrowed interpretation. A figure quoted on a forum, or remembered from another drive, arrives without the vendor's definition that gives it meaning, and the same number can sit on two drives carrying two different meanings. Where a definition cannot be read at its source, the honest move is the one this page makes with every threshold it leaves out: say so.
Where the read belongs in a diagnosis
A read of the drive's report is the first instrument out of the drawer because it is cheap, and the first to run out of things to say, because it speaks only about what the firmware counts. The gesture that follows is mechanical. Read, write it down, let the machine do the thing it was doing wrong, read again, and then decide which of the other two instruments the question needs.
If the question is whether a condition moves with load, that is the sensor's work, and the desk keeps a page on reading temperature and voltage sensors without overreading them. If the drive to be read sits in a machine that cannot be trusted to stay up, the read belongs to a system booted for the purpose, which is a subject of its own: a diagnosis from a live system. The gesture this page leaves with the reader is small enough to do tonight. Take the report now, while the drive behaves, put a date beside it, and put it where the next read will find it. A direction needs a start, and no tool supplies the start for you.
smartmontools.org is the site cited above for the definitions behind the tool, and it also publishes a wiki FAQ. When the desk consulted both pages, each returned the same bot verification screen, headed "Making sure you're not a bot!", with a loading notice and no description published. What sits behind that screen this page does not report, because it did not see it.