| Previous | Next |
| ERROR_TIERING_FILE_IS_NOT_PINNED | ERROR_ATTRIBUTE_NOT_PRESENT |
ERROR_NOT_A_TIERED_VOLUME
Identify the owner before touching the layout: not a tiered volume
The practical meaning of ERROR_NOT_A_TIERED_VOLUME (0x80830009) is tied to file-to-tier placement metadata for the addressed volume: the volume is accessible, but its backing virtual disk has no active multi-tier layout for the requested operation. The result does not, by itself, prove file-system corruption or physical-media failure.
Storage tiering operates above a tiered Storage Spaces virtual disk and records desired placement separately from normal file allocation while diagnosing this result. Optimization may move data according to heat, whereas pinning expresses an explicit placement preference for a supported file or volume object. This object model determines which identifiers, counts and ownership state are meaningful for it.
Diagnosis of this result should begin with the object model and generation current at the failure. A later successful enumeration may describe a replacement object and cannot retroactively validate the rejected request.
Minimum diagnostic set
| Storage diagnostic field | Value |
|---|---|
| Owning object | file-to-tier placement metadata for the addressed volume |
| Rejected invariant | the volume is accessible, but its backing virtual disk has no active multi-tier layout for the requested operation |
| Identity and generation | volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target |
| Narrow experiment | query the volume tier inventory and repeat the exact call on a known tiered Storage Spaces volume without changing the file or policy |
| Closest comparison | ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
Reproduce without destructive cleanup
- Before changing state for it, freeze the failing generation and save volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target while diagnosing this result.
- Exercise this exact comparison for it: query the volume tier inventory and repeat the exact call on a known tiered Storage Spaces volume without changing the file or policy.
- During the result comparison, keep image bytes, unrelated disks, provider policy and cluster topology fixed.
- After the test, record the next return value and the durable object state; crossing the boundary should expose a later result rather than silently retrying.
Use ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME as the nearest comparison. It is specific to the volume is accessible, but its backing virtual disk has no active multi-tier layout for the requested operation; the neighboring result belongs to another validation or lifecycle branch for it. Keeping both names prevents a generic storage label from hiding the actual owner.
Mechanism-specific note
It describes the configured layout, not a temporary provider outage. Enumerate storage tiers associated with the virtual disk and map the volume to that disk. If no tier relationship exists, the caller should use normal optimization or placement behavior rather than retrying a tier-only API while diagnosing it.
Restore the contract
Re-enumerate the volume, its storage tiers and the file object on the owner node; serialize optimization jobs and apply pinning only to supported objects on a live tiered volume while diagnosing it. After correcting it, reopen the pack, volume, tier, snapshot or virtual disk so no cached generation participates in the validation run.
- the first retry uses newly enumerated identifiers rather than cached handles.
- The durable metadata or provider state agrees with the success returned after it.
- A second run after close/reopen does not recreate the rejected the condition.
- the nearby
ERROR_TIERING_NOT_SUPPORTED_ON_VOLUMEpath remains separately testable and separately logged.
Before responding to it with destructive cleanup, prove which object owns the failure. Changing every disk or provider at once prevents a meaningful regression test.
Technical references
- Microsoft: MSFT_FileStorageTier class — use this source to verify tiering state and parameters for it.
- Microsoft: Set method of MSFT_FileStorageTier — documents the supported management path relevant to it.
- Microsoft: Optimize-Volume — defines the tiering objects used to interpret it.
- Microsoft: fsutil tiering — primary API or object-model reference for the boundary.
Looking for a different code? Search another status or error code.