# Volume states

The status and modification status values a volume reports, how asynchronous operations and failures show up in them, and which states are billed.

A volume reports two independent fields: `status` describes the volume itself, and `modificationStatus` describes the last resize. Creating, importing, resizing, and deleting a volume are asynchronous. The request returns as soon as the platform accepts it, and these fields tell you how the work ended.

## Status [#status]

What moves a volume between status values:

- Create or import: the volume starts `CREATING`, then becomes `AVAILABLE`, or `ERROR` if creation fails.
- Attach and detach: an `AVAILABLE` volume becomes `INUSE` when attached, and `AVAILABLE` again when detached.
- Delete: an `AVAILABLE` or `ERROR` volume moves to `DELETING`, then `DELETED`, or to `ERROR` if deletion fails. An `INUSE` volume moves to `DELETING` when its instance is terminated (see below).

| Status | Meaning | Billed | Counts against quota |
| --- | --- | --- | --- |
| `CREATING` | The platform is provisioning the volume. | No | Yes |
| `AVAILABLE` | The volume exists and isn’t attached to an instance. | Yes | Yes |
| `INUSE` | The volume is attached to an instance. `claimRef` names the attachment. | Yes | Yes |
| `DELETING` | The platform is removing the volume. | No | Yes |
| `DELETED` | The volume is gone. | No | No |
| `ERROR` | Creating or deleting the volume failed. `statusReason` says what failed. | No | Yes |

An `INUSE` volume moves to `DELETING` only when the instance it’s attached to is terminated and the volume is set to be deleted with it. A delete you request yourself is refused while the volume is attached. See [Delete a volume](/docs/storage/volumes/delete).

To see which instance holds an `INUSE` volume, see [Find the instance a volume is attached to](/docs/storage/volumes/find-instance).

## When an operation fails [#when-an-operation-fails]

A failed operation never reports success. The volume tells you what happened:

- A volume that couldn’t be created ends in `ERROR` instead of `AVAILABLE`. It has no usable disk behind it. Delete it and create a new one.
- A volume that couldn’t be deleted stays in your volume list as `ERROR` instead of reaching `DELETED`. Its disk may still exist, so it still counts against your quota. Delete it again once the cause is resolved.

`statusReason` is `null` for every status except `ERROR`. When set, it has the form `the operation failed (<code>)`, for example `the operation failed (ERR_IMPORT)`. For the codes an import can report, see [Import a disk image as a volume](/docs/storage/volumes/import).

Requests the platform can tell are invalid up front, such as deleting an attached volume or shrinking a volume, are refused immediately with an error. They never reach `ERROR`, and nothing about the volume changes.

## Modification status [#modification-status]

How `modificationStatus` tracks a resize: a resize moves it from `COMPLETED` to `RESIZING`. When the size is applied it returns to `COMPLETED`; if the resize fails it moves to `FAILED`, and another resize moves it to `RESIZING` again.

| Value | Meaning |
| --- | --- |
| `COMPLETED` | No resize is in progress. The last resize, if any, was applied. |
| `RESIZING` | A resize is in progress. `pendingSizeInGib` shows the target size. |
| `FAILED` | The last resize wasn’t applied. `modificationStatusReason` says why. |
| `MODIFYING` | A modification is in progress on a volume that reports no target size. Treat it like `RESIZING`. |

`sizeInGib` changes only after the platform confirms the new size, so it’s always a size the disk really has. While a resize runs, compare `sizeInGib` with `pendingSizeInGib` to tell “still in progress” from “didn’t happen”. A failed resize leaves the volume’s data and `sizeInGib` untouched. For details, see [Resize a volume](/docs/storage/volumes/resize).

## Settled states [#settled-states]

A state that has settled stays settled. Only something you do next changes it:

- A `DELETED` volume never reappears in your list and never returns to `ERROR`.
- An `ERROR` volume leaves that state only through another delete.
- A `FAILED` resize keeps its `modificationStatusReason` until you request another resize.

## Deleted volumes [#deleted-volumes]

A deleted volume drops out of your volume list immediately. You can still look it up by its URN with `origin storage get-volume` or the `pvs.volume` query, with no time limit, and it reports `DELETED`.

## A volume that outlived its instance [#a-volume-that-outlived-its-instance]

When you terminate an instance, the volumes created with it are normally deleted too. If one of them can’t be deleted, most often because a snapshot of it still exists, the platform keeps the volume instead of failing the termination. The volume is `AVAILABLE`, it’s yours, and it’s billed.

`retentionNote` on the volume explains why it was kept. It’s `null` on every other volume, including volumes you created yourself. To remove a kept volume, delete its snapshots and then the volume. See [Delete a volume](/docs/storage/volumes/delete).

## Related [#related]

- [Snapshot states](/docs/storage/snapshots/snapshot-states)
- [Troubleshoot storage](/docs/storage/troubleshooting)
- [Storage reference](/docs/storage/reference)