What a Storage Resilver Leaves for a Scrub to Check

Read the completion claim against the work it describes

Suppose a buyer receives a replacement offer promising that redundancy will be restored and the resilver will complete. That can describe a useful storage result while leaving a different question open: what examination of the rest of the pool is included?

The OpenZFS 2.3 scrub manual distinguishes data known to be out of date, selected for resilvering, from pool data selected for a normal scrub. The latter searches for silent corruption through checksum verification. Here, scrub means the normal survey, rather than the error-only variant.

A completion label inherits the scope of its operation. It cannot enlarge that scope merely because the replacement is new or the system is described as redundant again. Equally, a narrower examination is not evidence that corruption exists elsewhere. It leaves that wider question unanswered.

This makes the purchasing distinction more precise than repair versus check. The buyer needs to distinguish the population selected, the integrity work performed on it and the result reported. None of those can be filled in solely from the phrase replacement complete.

References: [ZR1]

Four regions make the coverage difference visible

Fictional example ZR-332 uses a quiescent mirrored set with four logical data regions. Let U = {A, B, C, D} be the complete data population in this simplified example. Stipulate that the known-out-of-date set is R = {B, D}, while the normal checksum-survey set is S = {A, B, C, D}.

R contains two region labels and S contains four. These symbolic sets describe fictional coverage, rather than physical I/O, capacity, timing or observed results. Their membership is stipulated; a different replacement or layout can select different data.

Here R is a subset of S, and S minus R = {A, C}. A report confined to R leaves the checksum condition of A and C outside its stated examination. Saying that B and D have been made current cannot supply that missing evidence.

To see why the difference matters, stipulate a silent corruption in A that has not placed A in R. Work directed at the stipulated out-of-date set does not establish discovery of that corruption. A belongs to the broader survey's target population; whether an actual survey detects an error and whether it can repair one remain outcome questions.

Conversely, if A and C are sound, the same coverage difference still exists. The example identifies an unanswered question, not a diagnosis.

Different selection rules also need not produce different-sized sets in every case. If all four regions were known to be out of date, R would equal S. That equality would not turn a resilver completion statement into a record of a completed normal scrub.

References: [ZR1]

A detected error still needs a usable reconstruction source

The OpenZFS 2.3 pool-concepts manual describes repair from a good copy and reconstruction from redundant storage, such as a mirror or applicable parity. Detecting that stored data disagrees with its checksum does not itself supply the missing correct contents.

Extend ZR-332 with two alternative conditions at A. In the first, the relevant redundancy supplies a usable good source. In the second, it supplies no usable way to reconstruct A. The same intended survey population can lead to different repair possibilities.

A replacement device adds somewhere to place reconstructed contents. Its presence alone does not establish that every required source is recoverable. Similarly, a report identifying errors is different from one establishing which errors were repaired and which remained unresolved.

For the buyer, survey coverage and repair outcome are independent parts of the offer. Broader coverage can expose a problem without guaranteeing its correction. A redundancy-restoration statement needs its actual result interpreted with the sources available to that operation.

References: [ZR3]

Sequential reconstruction explicitly separates restoration from checking

The OpenZFS 2.3 replacement manual documents a sequential reconstruction case that restores redundancy without verifying checksums during reconstruction. It starts a scrub when the resilver completes. The same passage states that sequential reconstruction is not supported for raidz configurations.

That documented sequence makes the completion boundary especially important. Reconstruction complete and checksum survey complete are separate milestones. A following scrub being started does not establish that it finished, what it examined successfully or what errors remained.

An offer referring to this case should keep the reconstruction result separate from the following scrub's result.

Do not extend this exception into a claim that every resilver skips checksum verification. Its relevance depends on the documented mode and offered implementation. Another release or storage product requires its own evidence.

References: [ZR2]

Metadata scanning is a different stage from block checking

The normal-scrub documentation also separates metadata scanning from block scrubbing. Metadata scanning organizes blocks into larger sequential ranges for the subsequent I/O.

A report that metadata referencing A has been scanned does not establish that A has completed checksum verification. Identify which stage a progress statement describes before treating it as a checking result.

References: [ZR1]

A consistent pool can still hold the wrong application generation

Even a completed survey with no reported checksum errors answers a storage-integrity question. It does not independently know what the application intended to save.

Consider an additional fictional condition: the application requires generation G7, but the retained data contains only an earlier generation G6. Stipulate that every stored region belonging to G6 agrees with its recorded checksum. A checksum survey can find those stored contents consistent without establishing the presence of G7. No corruption is needed for the application requirement to remain unmet.

The same reasoning applies to meaning: a wrong value supplied by an application can be stored consistently, without ever being compared with a separate business or scientific expectation.

Nor does examining the current pool create a separately retained recovery copy. Backup retention, the desired recovery point and the application's required components remain separate decisions. Use the related training-checkpoint and storage-snapshot guide to identify the application state and recovery point a retained copy must contain.

The useful interpretation therefore keeps three claims distinct: redundancy was restored for the stated operation, the stated checksum survey achieved its reported result, and the required application state is available. Evidence for one claim cannot silently supply the others.

Keep the physical replacement package tied to its own result

Before comparing prices, have the storage provider distinguish the proposed replacement and redundancy-restoration result from any included checksum survey and application return. Retain the OpenZFS version, applicable reconstruction mode and separately reported outcomes with that explanation. Missing information calls for clarification; it does not establish a failed pool.

If the resulting plan includes an approved physical equipment change, Leviathan's Hardware Refresh & Physical Support service provides a relevant place to discuss equipment replacement, recabling and revised handoff records. The related service and project inquiry concern that physical work.

Share a nonconfidential equipment summary, approved replacement identities, site, appointed parts supplier and requested physical outputs. The storage and application owners retain configuration, data handling and return-to-service decisions. A physical replacement record cannot close the checksum-coverage or application-state questions described above.

References: [L1]