# Resize a volume

Grow a volume, including one attached to a running instance, then extend the partition and filesystem inside the guest to use the new space.

Grow a volume when it runs out of space. You can grow a volume while it’s attached to a running instance, without a restart. Volumes only grow: there’s no way to make a volume smaller.

## Before you begin [#before-you-begin]

<BeforeYouBegin>

- The volume’s URN.
- Permission `pvs.volume.update` on the volume. See [Roles](/docs/iam/roles).
- A volume that reports `AVAILABLE` or `INUSE`. A volume in `CREATING` can’t be resized yet; wait for `AVAILABLE`. A volume in `DELETING`, `DELETED`, or `ERROR` can’t be resized.
- No other resize in progress: `modificationStatus` is `COMPLETED` or `FAILED`.
- An active organization and a billing account that can pay. For card-managed billing, that means a verified payment method. See [Add a payment method](/docs/platform/billing/payment-method).
- Quota headroom for the growth. Only the growth counts: taking a 100 GiB volume to 120 GiB needs 20 GiB of headroom. See [Limits](/docs/platform/reference/limits).

</BeforeYouBegin>

## Resize the volume [#resize-the-volume]

1. Check the volume’s current `sizeInGib`, `status`, and `modificationStatus`.

   ```sh
   origin storage get-volume --volume-urn <volume-urn>
   ```

1. Request a size larger than the current `sizeInGib`.

   ```sh
   origin storage resize-volume --volume-urn <volume-urn> \
     --size-in-gib 120
   ```

   With the API, use the `resizeVolume` mutation:

   ```graphql
   mutation {
     pvs {
       resizeVolume(input: {
         volumeUrn: "<volume-urn>"
         sizeInGib: 120
       }) {
         accepted
         message
       }
     }
   }
   ```

   The volume reports `modificationStatus: RESIZING`, and `pendingSizeInGib` shows the target size.

1. Check the volume until `modificationStatus` reports `COMPLETED` and `sizeInGib` shows the new size.

   ```sh
   origin storage get-volume --volume-urn <volume-urn>
   ```

## Use the new space inside the guest [#use-the-new-space-inside-the-guest]

The platform grows the block device. It doesn’t change the partition table or the filesystem on it.

- On a running instance, the guest sees the larger disk without a restart. Grow the partition and then the filesystem, for example with `growpart` and the filesystem’s own grow command. Many images do this at boot, so a restart also makes the space appear.
- On a stopped instance or a detached volume, nothing is needed now. The instance sees the new size the next time it starts.

## What the platform refuses [#what-the-platform-refuses]

These requests are refused immediately with an error, and nothing about the volume changes, not even `modificationStatus`:

- A size equal to or smaller than the current `sizeInGib`. Shrinking would truncate the filesystem on the disk. To use less storage, create a smaller volume, copy your data across at file level, and delete the old volume. A volume created from a snapshot can’t be smaller than the snapshot’s source volume, so a snapshot doesn’t help here.
- A volume in a state other than `AVAILABLE` or `INUSE`.
- A resize while another one is in progress.
- A resize that would exceed your volume storage quota, from an inactive organization, or from a project whose billing account can’t pay.

If your usage is already over a limit, for example because the limit was lowered, no resize brings you back under it. Deleting volumes you no longer need frees quota, and a delete is never held to a quota.

## If this fails [#if-this-fails]

If the platform accepts the resize but can’t apply it, `modificationStatus` reports `FAILED` with a `modificationStatusReason`. The volume’s data is intact and `sizeInGib` still reports its real size. Request the resize again.

## Related [#related]

- [Volume states](/docs/storage/volumes/volume-states)
- [`resize-volume` command](/docs/storage/reference/cli#resize-volume)
- [Troubleshoot storage](/docs/storage/troubleshooting)