What does HRESULT 0x80830006 (ERROR_TIERING_ALREADY_PROCESSING) mean?

ERROR_TIERING_ALREADY_PROCESSING

Read the code at the owning storage layer: tiering already processing

ERROR_TIERING_ALREADY_PROCESSING has unsigned value 0x80830006. In the tiering layer, it rejects a specific contract because a tier optimization or placement operation already owns the per-volume worker and a second run cannot start concurrently for it. Diagnosis of this result should follow file-to-tier placement metadata for the addressed volume through one controlled state transition.

Storage tiering operates above a tiered Storage Spaces virtual disk and records desired placement separately from normal file allocation. 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.

Keep the first result attached to its request parameters and object generation while diagnosing this result. Cleanup failures or a later drive-letter change are secondary evidence, not replacements for the original boundary.

Build a trustworthy incident record

When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result for it.

Controlled comparison

1. Associate this result with one caller, one transaction and one target UniqueId while diagnosing it.
2. Save the pre-call and post-call inventories, including volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target.
3. Use this A/B case for it without touching unrelated storage: observe one Optimize-Volume tier job, issue the second request while it is active, then retry only after the first job reaches a terminal state while diagnosing this result.
4. Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle for it.

Use ERROR_TIERING_VOLUME_DISMOUNT_IN_PROGRESS as the nearest comparison. It is specific to a tier optimization or placement operation already owns the per-volume worker and a second run cannot start concurrently; the neighboring result belongs to another validation or lifecycle branch. Keeping both names prevents a generic storage label from hiding the actual owner while diagnosing it.

Mechanism-specific note

Tier optimization is a serialized background job with measurable progress and a terminal result. Identify the running job rather than starting another for it. A scheduler should coalesce duplicate requests and re-evaluate placement after completion instead of using a fixed retry loop.

Completion criteria

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. Keep the correction scoped to the owning object and avoid rewriting adjacent metadata merely to make the call return success for it.

• 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_VOLUME_DISMOUNT_IN_PROGRESS path remains separately testable and separately logged.

A reboot, blanket disk conversion or deletion of storage metadata is not a justified first response to it; it changes multiple invariants and can erase the evidence needed to identify the defect.

Technical references

• Microsoft: MSFT_FileStorageTier class — documents the supported management path relevant to it.
• Microsoft: Set method of MSFT_FileStorageTier — defines the tiering objects used to interpret it.
• Microsoft: Optimize-Volume — primary API or object-model reference for the boundary.
• Microsoft: fsutil tiering — use this source to verify tiering state and parameters for it.

Looking for a different code? Search another status or error code.