J'ai suivi les étapes pour redimensionner un volume EC2
L'ancien volume faisait 5 Go et celui que j'ai créé est 100 Go. Maintenant, quand je redémarre l'instance et lance df -h I
, Je vois encore ceci
Filesystem Size Used Avail Use% Mounted on
/dev/xvde1 4.7G 3.5G 1021M 78% /
tmpfs 296M 0 296M 0% /dev/shm
C'est ce que je reçois quand je cours
Sudo resize2fs /dev/xvde1
The filesystem is already 1247037 blocks long. Nothing to do!
Si je lance cat /proc/partitions
Je vois
202 64 104857600 xvde
202 65 4988151 xvde1
202 66 249007 xvde2
D'après ce que je comprends si j'ai suivi les bonnes étapes, xvde devrait avoir les mêmes données que xvde1 mais je ne sais pas comment les utiliser.
Comment puis-je utiliser le nouveau volume ou umount xvde1 et monter xvde à la place?
Je ne peux pas comprendre ce que je fais mal
J'ai aussi essayé Sudo ifs_growfs /dev/xvde1
xfs_growfs: /dev/xvde1 is not a mounted XFS filesystem
Btw, c'est une boîte Linux avec centos 6.2 x86_64
Merci d'avance pour votre aide
Merci Wilman, vos commandes ont fonctionné correctement. De petites améliorations doivent être envisagées si nous augmentons les EBS dans des tailles plus grandes.
/dev/sda1
)Accédez à l'instance via SSH et exécutez fdisk /dev/xvde
AVERTISSEMENT: le mode compatible DOS est obsolète. Il est fortement recommandé de désactiver le mode (commande 'c') et de modifier les unités d'affichage en secteurs (commande 'u')
Frappé p pour afficher les partitions actuelles
partprobe
(du paquet parted
.) Pour informer le noyau de la nouvelle table de partitions. Inutile d'arrêter l'instance et de détacher le volume EBS pour le redimensionner!
13-Feb-2017 Amazon a annoncé: " Mise à jour Amazon EBS - Les nouveaux volumes Elastic Change Everything "
Le processus fonctionne même si le volume à étendre est le volume racine de l'instance en cours d'exécution!
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /
Comme vous pouvez le constater,/dev/xvda1 a encore 8 GiB partition sur un périphérique 16 GiB et qu'il n'y a pas d'autres partitions sur le volume. Utilisons "growpart" "redimensionner une partition 8G jusqu’à 16G:
# install "cloud-guest-utils" if it is not installed already
apt install cloud-guest-utils
# resize partition
growpart /dev/xvda 1
Vérifions le résultat (vous pouvez voir que/dev/xvda1 est maintenant 16G):
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 16G 0 part /
De nombreuses réponses SO suggèrent d'utiliser fdisk avec des partitions de suppression/recréation, processus méchant, risqué et sujet aux erreurs, en particulier lorsque nous changeons de lecteur.
# Check before resizing ("Avail" shows 1.1G):
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.8G 6.3G 1.1G 86% /
# resize filesystem
resize2fs /dev/xvda1
# Check after resizing ("Avail" now shows 8.7G!-):
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 16G 6.3G 8.7G 42% /
Nous n'avons donc aucun temps d'arrêt et beaucoup de nouveaux espaces à utiliser.
Prendre plaisir!
Commentaire du préfet de jperelli ci-dessus.
J'ai rencontré le même problème aujourd'hui. La documentation AWS ne mentionne pas clairement growpart. J'ai compris à la dure et les deux commandes fonctionnaient parfaitement sur M4.large & M4.xlarge avec Ubuntu
Sudo growpart /dev/xvda 1
Sudo resize2fs /dev/xvda1
[RESOLU]
C'est ce qu'il fallait faire
fdisk /dev/xvde
resize2fs /dev/xvde1
df -h
Ça y est
Bonne chance!
connectez-vous à la console Web AWS -> EBS -> cliquez avec le bouton droit de la souris sur celle que vous souhaitez redimensionner -> "Modifier le volume" -> modifiez le champ "Taille" et cliquez sur le bouton [Modifier]
growpart /dev/xvda 1
resize2fs /dev/xvda1
Ceci est une version précise de la réponse de Dmitry Shevkoplyas. La documentation AWS n'affiche pas la commande growpart
. Cela fonctionne bien pour AMI Ubuntu.
les deux commandes ci-dessus m'ont permis de gagner du temps pour les instances AWS ubuntu ec2.
Avez-vous créé une partition sur ce volume? Si vous le faites, vous devrez d'abord agrandir la partition.
Cela fonctionnera pour le système de fichiers xfs, exécutez simplement cette commande
xfs_growfs /
Juste au cas où si quelqu'un ici pour la plate-forme cloud Google GCP,
Essaye ça:
Sudo growpart /dev/sdb 1
Sudo resize2fs /dev/sdb1
L'indicateur d'amorçage (a) n'a pas fonctionné dans mon cas (EC2, centos6.5), j'ai donc dû recréer un volume à partir d'un instantané. Après avoir répété toutes les étapes SAUF drapeau amorçable - tout fonctionnait parfaitement, ainsi j’ai pu redimensionner2fs après. Merci!
Je n'ai pas assez de rep pour commenter ci-dessus; mais notez également par les commentaires ci-dessus que vous pouvez corrompre votre instance si vous commencez à 1; si vous appuyez sur "u" après avoir démarré fdisk avant de répertorier vos partitions avec "p", vous obtiendrez le bon numéro de démarrage afin que vous ne corrompiez pas vos volumes. Pour centos 6,5 AMI, comme mentionné ci-dessus, 2048 était exact pour moi.
Donc, au cas où quelqu'un aurait eu le problème où ils ont rencontré ce problème avec une utilisation à 100% et sans espace pour même exécuter la commande growpart (car cela crée un fichier dans/tmp)
Voici une commande que j'ai trouvée qui contourne même lorsque le volume EBS est utilisé, et aussi s'il ne reste plus d'espace sur votre ec2 et que vous êtes à 100%
/sbin/parted ---pretend-input-tty /dev/xvda resizepart 1 yes 100%
voir ce site ici:
https://www.elastic.co/blog/autoresize-ebs-root-volume-on-aws-amis
Merci, @ Dimitry, cela a fonctionné comme un charme avec une petite modification pour correspondre à mon système de fichiers.
Utilisez ensuite la commande suivante en remplaçant le point de montage du système de fichiers (les systèmes de fichiers XFS doivent être montés pour les redimensionner):
[ec2-user ~]$ Sudo xfs_growfs -d /mnt
meta-data=/dev/xvdf isize=256 agcount=4, agsize=65536 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262144, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 262144 to 26214400
Remarque Si vous recevez un échec de xfsctl: impossible d'allouer une erreur de mémoire, vous devrez peut-être mettre à jour le noyau Linux sur votre instance. Pour plus d'informations, reportez-vous à la documentation de votre système d'exploitation. Si vous recevez un Le système de fichiers est déjà nnnnnnn bloc longtemps. Rien à faire! erreur, voir Développement d’une partition Linux.