Résoudre les problèmes liés aux disques saturés et au redimensionnement des disques
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Linux
Cette page décrit les problèmes courants que vous pouvez rencontrer lors du redimensionnement d'un disque persistant ou lorsque votre disque persistant est saturé, et explique comment les résoudre.
Si ce n'est pas déjà fait, configurez l'authentification.
L'authentification valide votre identité pour accéder aux services et aux API Google Cloud . Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes :
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and
APIs, you don't need to set up authentication.
gcloud
Installez la Google Cloud CLI.
Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante :
Pour utiliser les exemples API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à la gcloud CLI.
Installez la Google Cloud CLI.
Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante :
Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud .
Taux d'erreur limité lors de la modification d'un disque
Voici les erreurs courantes que vous pouvez rencontrer lorsque vous essayez de modifier votre disque persistant extrême ou Google Cloud Hyperdisk. Ces erreurs peuvent apparaître à plusieurs endroits, par exemple dans la sortie de la console série ou dans les journaux d'application.
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.
Passer en revue les limites temporelles suivantes pour la modification des disques :
Vous ne pouvez redimensionner un volume de disque persistant extrême ou Hyperdisk Throughput qu'une fois par période de 6 heures.
Vous ne pouvez redimensionner un volume Hyperdisk Extreme qu'une fois par période de quatre heures.
Vous ne pouvez modifier les IOPS ou le débit provisionné pour un volume Hyperdisk qu'une fois par période de quatre heures.
Pour résoudre ces erreurs, attendez la durée requise depuis votre dernière modification avant d'essayer de modifier à nouveau les disques.
Erreurs de capacité des disques
Disques saturés
Voici les erreurs courantes que vous pouvez rencontrer lorsque votre disque persistant atteint sa capacité maximale. Ces erreurs peuvent apparaître à plusieurs endroits, par exemple dans la sortie de la console série ou dans les journaux d'application.
No space left on device
Not enough storage is available to process this command
VM inaccessible en raison d'un disque de démarrage saturé
Votre VM peut devenir inaccessible si son disque de démarrage est saturé. Ce scénario peut être difficile à identifier : il n'est pas toujours évident de savoir si le problème de connectivité des VM est dû à un disque de démarrage saturé. Vous trouverez ci-dessous des exemples d'erreurs courantes que vous pouvez rencontrer si vous ne pouvez pas accéder à votre VM à partir de Google Cloud CLI, en raison d'une saturation du disque de démarrage :
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', '/']...
Pour résoudre les problèmes ci-dessus, procédez comme suit :
Vérifiez que l'échec SSH de la VM est dû à un disque de démarrage saturé :
Après avoir redimensionné le disque de démarrage d'une VM, la plupart des VM redimensionnent le système de fichiers racine et effectuent un redémarrage. Toutefois, pour certains types d'images de VM, vous devrez peut-être redimensionner le système de fichiers manuellement. Si votre VM n'est pas compatible avec le redimensionnement automatique du système de fichiers racine, ou si vous avez redimensionné un disque persistant de données (non amorçable), vous devez redimensionner manuellement le système de fichiers et les partitions.
Pour vérifier si votre système de fichiers racine a été développé automatiquement après avoir redimensionné le disque de démarrage de la VM, procédez comme suit :
Vérifiez si votre VM a redimensionné le disque de démarrage en utilisant l'une des méthodes suivantes :
Par exemple, sur les VM avec des images Debian, si le redimensionnement automatique a réussi, les journaux de la console incluent la ligne ... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1.
Si vous pouvez vous connecter en SSH à une VM Linux, exécutez la commande df -h pour vérifier l'espace disque disponible.
Par exemple, ce résultat indique que le système de fichiers racine est plein à 92 % :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eThis document outlines common issues encountered when resizing or managing full persistent disks in Linux environments.\u003c/p\u003e\n"],["\u003cp\u003eIt provides solutions for rate-limited errors when modifying Extreme Persistent Disks or Hyperdisks, including waiting for specific timeframes.\u003c/p\u003e\n"],["\u003cp\u003eThe content details how to address disk capacity errors, including full disks and inaccessible VMs due to a full boot disk, by creating snapshots, deleting unnecessary files, or resizing the disk.\u003c/p\u003e\n"],["\u003cp\u003eIt explains how to determine if a root file system was automatically resized after increasing a VM boot disk's size, and provides instructions for manually resizing the file system if needed.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot full disks and disk resizing\n\nLinux\n\n*** ** * ** ***\n\nThis page describes common issues that you might run into when resizing a\npersistent disk or when your persistent disk is full, and how to fix each of\nthem.\n\nBefore you begin\n----------------\n\n- Always [create a snapshot of\n your disk](/compute/docs/disks/create-snapshots) before performing any troubleshooting steps to ensure that your data is backed up.\n- If you haven't already, set up [authentication](/compute/docs/authentication). Authentication verifies your identity for access to Google Cloud services and APIs. To run code or samples from a local development environment, you can authenticate to Compute Engine by selecting one of the following options:\n\n Select the tab for how you plan to use the samples on this page: \n\n ### Console\n\n\n When you use the Google Cloud console to access Google Cloud services and\n APIs, you don't need to set up authentication.\n\n ### gcloud\n\n 1.\n [Install](/sdk/docs/install) the Google Cloud CLI.\n\n After installation,\n [initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n ```bash\n gcloud init\n ```\n\n\n If you're using an external identity provider (IdP), you must first\n [sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n | **Note:** If you installed the gcloud CLI previously, make sure you have the latest version by running `gcloud components update`.\n 2. [Set a default region and zone](/compute/docs/gcloud-compute#set_default_zone_and_region_in_your_local_client).\n\n ### REST\n\n\n To use the REST API samples on this page in a local development environment, you use the\n credentials you provide to the gcloud CLI.\n 1. [Install](/sdk/docs/install) the Google Cloud CLI. After installation, [initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command: \n\n ```bash\n gcloud init\n ```\n 2. If you're using an external identity provider (IdP), you must first [sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n\n For more information, see\n [Authenticate for using REST](/docs/authentication/rest)\n in the Google Cloud authentication documentation.\n\nRate limited error when modifying a disk\n----------------------------------------\n\nThe following are common errors you might encounter when you attempt to\nmodify your Extreme Persistent Disk or Google Cloud Hyperdisk. You might see these\nerrors appear in a number of places, such as in your serial console output or\nin application logs.\n\n```\nDisk cannot be resized due to being rate limited.\n``` \n\n```\nCannot update provisioned iops due to being rate limited.\n``` \n\n```\nCannot update provisioned throughput due to being rate limited.\n```\n\nReview the following time limits for modifying disks:\n\n- You can resize an Extreme Persistent Disk or Hyperdisk Throughput volume only once in a 6 hour period.\n- You can resize a Hyperdisk Extreme volume only once in a 4 hour period.\n- You can change the provisioned IOPS or throughput for a Hyperdisk volume only once in a 4 hour period.\n\nTo resolve these errors, wait the required amount of time since your last\nmodification before attempting to modify the disks again.\n\nDisk capacity errors\n--------------------\n\n### Full disks\n\nThe following are common errors you might encounter when your persistent disk\nreaches full capacity. You might see these errors appear in a number of places,\nsuch as in your serial console output or in application logs.\n\n```\nNo space left on device\n``` \n\n```\nNot enough storage is available to process this command\n```\n\nTo resolve this issue, do the following:\n\n1. [Create a snapshot](/compute/docs/disks/create-snapshots#creating_snapshots)\n of the disk.\n\n2. Delete files that you don't need on the disk to free up space.\n\n3. If your disk requires more space after this, [resize the disk](/compute/docs/disks/resize-persistent-disk).\n\n### Inaccessible VM due to full boot disk\n\nYour VM might become inaccessible if its boot disk is full. This scenario can be\ndifficult to identify; it's not always obvious when the VM connectivity issue\nis due to a full boot disk. The following are examples of common errors you\nmight encounter if you cannot access your VM from the Google Cloud CLI because\nthe boot disk is full:\n\n```\n Network error: Software caused connection abort\n \n``` \n\n```\n ERROR: (gcloud.compute.ssh) Could not SSH into the instance. It is possible\n that your SSH key has not propagated to the instance yet. Try running this\n command again. If you still cannot connect, verify that the firewall and\n instance are set to accept ssh traffic.\n \n``` \n\n```\n You cannot connect to the VM instance because of an unexpected error. Wait a\n few moments and then try again.\n \n``` \n\n```\n No space left on device\n \n``` \n\n```\n ERROR Exception calling the response handler. [Errno 2] No usable temporary\n directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']...\n \n```\n\nTo resolve the above issues, do the following:\n\n1. Confirm that the VM's SSH failure is due to a full boot disk:\n\n ```\n gcloud compute instances tail-serial-port-output VM_NAME\n ```\n\n If the boot disk is full, the resulting output will contain the message `No\n space left on device`.\n2. If you have not already done so, [create a snapshot](/compute/docs/disks/create-snapshots#creating_snapshots)\n of the VM's boot disk.\n\n3. Try to [restart the VM](/compute/docs/instances/stop-start-instance#stopping_a_vm).\n\n4. If you still can't access the VM, do the following:\n\n 1. Stop the VM:\n\n ```\n gcloud compute instances stop VM_NAME\n ```\n\n Replace \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e with the name of your VM.\n 2. Increase the size of the boot disk:\n\n ```\n gcloud compute disks resize BOOT_DISK_NAME --size DISK_SIZE\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eBOOT_DISK_NAME\u003c/var\u003e: the name of your VM's boot disk\n - \u003cvar translate=\"no\"\u003eDISK_SIZE\u003c/var\u003e: the new larger size, in gigabytes, for the boot disk\n\n For example, to resize a disk named `example-disk-1` to 6GB, run\n the following command: \n\n ```\n gcloud compute disks resize example-disk-1 --size=6GB\n ```\n 3. Start the VM:\n\n ```\n gcloud compute instances start VM_NAME\n ```\n5. Reattempt to [SSH to the VM](/compute/docs/instances/connecting-to-instance).\n If you still can't access the VM, do one of the following:\n\n - Create a new disk from a snapshot. For more information, see\n [Recovering an inaccessible VM or a full boot disk](/compute/docs/disks/recover-vm#inaccessible_instance).\n\n - Boot the VM temporarily in rescue mode, using open source\n [GCE Rescue tool](https://github.com/googlecloudplatform/gce-rescue)\n and perform the steps available in [File system issues](#filesystem).\n\nFile system issues\n------------------\n\n### File system resize\n\nAfter you resize a VM boot disk, most VMs resize the root file system and\nrestart the VM. However, for some VM images types, you might have to resize the\nfile system manually. If your VM does not support automatic root file\nsystem resizing, or if you've resized a data (non-boot) persistent disk, you\nmust manually [resize the file system and partitions](/compute/docs/disks/resize-persistent-disk).\n\nTo check if your root file system expanded automatically after you resized your\nVM boot disk, do the following:\n\n1. Check if your VM resized the boot disk using one of the following methods:\n\n - [Inspect your serial port output](/compute/docs/instances/viewing-serial-port-output).\n Look for a line that indicates the root partition was resized.\n\n For example, on VMs with Debian images, if the automatic resize was\n successful then the console logs include the line\n `... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1`.\n - If you can connect to a Linux VM using SSH, run the command `df -h` to\n check if there is free disk space.\n\n For example, this output shows that the root file system is 92%\n full: \n\n ```\n Filesystem Size Used Avail Use% Mounted on\n udev 63G 0 63G 0% /dev\n tmpfs 13G 1.4M 13G 1% /run\n /dev/sda1 339G 315G 24G 92% /\n ```\n2. If your VM didn't resize the root file system, manually [resize the file\n system and partitions](/compute/docs/disks/resize-persistent-disk)."]]