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, the operation is rejected because a tier optimization or placement operation already owns the per-volume worker and a second run cannot start concurrently. 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.

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

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.

Controlled comparison

1. Associate this result with one caller, one transaction and one target UniqueId.
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 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.
4. Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle.

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.

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. 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.

• 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 condition.
• the nearby ERROR_TIERING_VOLUME_DISMOUNT_IN_PROGRESS path remains separately testable and separately logged.

Technical references

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