Troubleshoot full disks and disk resizing

Linux Windows

This page describes common issues that you might run into when resizing apersistent disk or when your persistent disk is full, and how to fix each ofthem.

Before you begin

Rate limited error when modifying a disk

The following are common errors you might encounter when you attempt tomodify your Extreme Persistent Disk or Google Cloud Hyperdisk. You might see theseerrors appear in a number of places, such as in your serial console output orin application logs.

    Disk cannot be resized due to being rate limited.
    Cannot update provisioned iops due to being rate limited.
    Cannot update provisioned throughput due to being rate limited.

Review the following time limits for modifying disks:

  • You can resize an Extreme Persistent Disk or Hyperdisk Throughputvolume only once in a 6 hour period.
  • You can resize a Hyperdisk Extreme volume only once in a 4hour period.
  • You can change the provisioned IOPS or throughput for aHyperdisk volume only once in a 4 hour period.

To resolve these errors, wait the required amount of time since your lastmodification before attempting to modify the disks again.

Disk capacity errors

Full disks

The following are common errors you might encounter when your persistent diskreaches full capacity. You might see these errors appear in a number of places,such as in your serial console output or in application logs.

    No space left on device
    Not enough storage is available to process this command

To resolve this issue, do the following:

  1. Create a snapshotof the disk.

  2. Delete files that you don't need on the disk to free up space.

  3. If your disk requires more space after this,resize the disk.

Inaccessible VM due to full boot disk

Your VM might become inaccessible if its boot disk is full. This scenario can bedifficult to identify; it's not always obvious when the VM connectivity issueis due to a full boot disk. The following are examples of common errors youmight encounter if you cannot access your VM from the Google Cloud CLI becausethe boot disk is full:

      Network error: Software caused connection abort
      ERROR: (gcloud.compute.ssh) Could not SSH into the instance.  It is possible  that your SSH key has not propagated to the instance yet. Try running this  command again.  If you still cannot connect, verify that the firewall and  instance are set to accept ssh traffic.
      You cannot connect to the VM instance because of an unexpected error. Wait a  few moments and then try again.
      No space left on device
      ERROR Exception calling the response handler. [Errno 2] No usable temporary  directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']...

To resolve the above issues, do the following:

  1. Confirm that the VM's SSH failure is due to a full boot disk:

    gcloud compute instances tail-serial-port-outputVM_NAME

    If the boot disk is full, the resulting output will contain the messageNospace left on device.

  2. If you have not already done so,create a snapshotof the VM's boot disk.

  3. Try torestart the VM.

  4. If you still can't access the VM, do the following:

    1. Stop the VM:

      gcloud compute instances stopVM_NAME

      ReplaceVM_NAME with the name of your VM.

    2. Increase the size of the boot disk:

      gcloud compute disks resizeBOOT_DISK_NAME --sizeDISK_SIZE

      Replace the following:

      • BOOT_DISK_NAME: the name of your VM's bootdisk
      • DISK_SIZE: the new larger size, ingigabytes, for the boot disk

      For example, to resize a disk namedexample-disk-1 to 6GB, runthe following command:

      gcloud compute disks resize example-disk-1 --size=6GB
    3. Start the VM:

      gcloud compute instances startVM_NAME
  5. Reattempt toSSH to the VM.If you still can't access the VM, do one of the following:

File system issues

File system resize

After you resize a VM boot disk, most VMs resize the root file system andrestart the VM. However, for some VM images types, you might have to resize thefile system manually. If your VM does not support automatic root filesystem resizing, or if you've resized a data (non-boot) persistent disk, youmust manuallyresize the file system and partitions.

To check if your root file system expanded automatically after you resized yourVM boot disk, do the following:

  1. Check if your VM resized the boot disk using one of the following methods:

    • Inspect your serial port output.Look for a line that indicates the root partition was resized.

      For example, on VMs with Debian images, if the automatic resize wassuccessful then the console logs include the line... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1.

    • If you can connect to a Linux VM using SSH, run the commanddf -h tocheck if there is free disk space.

      For example, this output shows that the root file system is 92%full:

      Filesystem                                    Size  Used Avail Use% Mounted onudev                                           63G     0   63G   0% /devtmpfs                                          13G  1.4M   13G   1% /run/dev/sda1                                     339G  315G   24G  92% /
  2. If your VM didn't resize the root file system, manuallyresize the filesystem and partitions.

Storage Spaces Direct (S2D) limitation

When using Storage Spaces Direct (S2D), you can't increase capacity byresizing underlying persistent disks. If you resize disks at the hardwarelevel, S2D won't recognize the added space, and data might become inaccessible. To increase capacity,add servers or drives instead of resizing existing persistent disks.

To check if the disk is configured as part of an S2D cluster or storage pool, complete the following steps:

  1. In the Google Cloud console, go to theVM instances page.

    Go to VM instances

  2. Next to the instance that has the resized disk, click theRDP button. The browser opens an RDP connection to the instance.

  3. Right-click theWindows Start button and selectDisk Management to open theDisk Management tool.For example, the following screenshot shows that Disk 1 has a Storage Spaces protective partition in place:

S2D details from Disk Management.

Alternatively, you can run either of the following PowerShell commands to find any Persistent Disk that are associated with a S2D configuration.

       Get-Disk | Where-Object Model -eq "Storage Space"
       Get-PhysicalDisk | Where-Object {$_.ObjectId -like "*Spaces*"}

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-12-15 UTC.