Forum Linux.redhat Resize2fs à chaud qui dure...

Posté par  (site web personnel) .
Étiquettes : aucune
0
8
juin
2010
Bonjour,

Afin de prévenir d'éventuels soucis d'espace, j'ai décidé de retailler la partion /var (ext3 sur un volume LVM) d'un serveur sous RHEL5.4.
J'ai lu que resize2fs permettait maintenant de le faire à chaud, ce qui m'arrange dans ce cas.

Voila donc ce que j'ai fait :

[root@server6 ~]# lvresize -L 4G /dev/mapper/vg00-lvsys03
Extending logical volume lvsys03 to 4.00 GB
Logical volume lvsys03 successfully resized
[root@server6 ~]# resize2fs /dev/mapper/vg00-lvsys03
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/mapper/vg00-lvsys03 is mounted on /var; on-line resizing required
Performing an on-line resize of /dev/mapper/vg00-lvsys03 to 1048576 (4k) blocks.


Et depuis, plus rien. Ma connexion SSH est toujours là (quand j'appuie sur 'entrée', j'ai bien des retours chariots), mais je ne peux pas en ouvrir une autre (je reste en attente après la saisie du mot de passe)

J'ai bien lu que cette opération pouvait durer longtemps, mais là cela va faire 4h pour passer de 1 à 4Go. Donc si quelqu'un a une idée de la durée à partir de laquelle on doit s'inquiéter...

J'hésite aussi à tenter un Ctrl-z sur la commande pour essayer de voir où ça en est et tenter un dmesg, je ne sais pas si c'est très conseillé sur un resize2fs.
Je ne sais pas non plus dans quel état je risque de retrouver ma partition si je finis par stopper la commande par un Ctrl-c.
Si quelqu'un a des idées...

jC

  • # A condition

    Posté par  . Évalué à 3.

    Ca marche 'online' à condition que le fsck (pas online) soit ok...
    C'est peut être mal partit ici.

    La deuxième chose, c'est que pour faire un resizing, un lock est placé sur le système de fichiers, ce qui bloque toutes les autres applications. Si la machine n'a pas ses services stoppés (et sa montée en charge non limitée), les process (genre web) en file d'attente risquent de taper dans la swap et la vrille commence...

    • [^] # Re: A condition

      Posté par  (site web personnel) . Évalué à 1.

      Pour le fsck, je ne me suis pas posé la question, l'installation datant de quelques jours, sans reboot violent ou crash. Quoi qu'il en soit, je pense que s'il y avait un problème d'intégrité, ça aurait été à resize2fs de me prévenir, ou de refuser son exécution sans fsck préalable (ce qui était le cas avant lors des retaillages fs démonté si je me souviens bien)

      Pour la deuxième chose, j'ai effectivement un serveur MySQL qui écrit dans /var, mais j'avais locké les tables d'abord. D'autres services systèmes devaient eux aussi écrire leurs logs par exemple, ou du moins avoir des fichiers ouverts, mais *justement*, c'était le but du resize2fs *online*...

  • # À chaud pas trop recommandé.

    Posté par  . Évalué à 3.

    Je ne suis pas certain que resize2fs.ext3 fasse du retaillage à chaud.

    En tout cas, sur nos serveurs, on ne fait pas de retaillage à chaud. De plus ça a l’air de coincer, le retaillage se fait en quelques secondes.

    La méthode sur CentOS (RHEL-like), on passe le système en niveau 1 (mono-utilisateur), ça stoppe les services, on retaille tranquillement (à condition qu’aucun processus utilisant /var n’ait survecu à l’arrêt des services), et on repasse en niveau de production (3, 4 ou 5 etc.).

    Temps d’indisponibilité de 5 min max si aucun problème de processus.

    Si tu as un accès physique à ta machine, précipite y toi :)

    • [^] # Re: À chaud pas trop recommandé.

      Posté par  (site web personnel) . Évalué à 1.

      Si, si, resize2fs fait bien du retaillage à chaud, même pour ext3. J'allais chercher une référence en ligne, mais la réponse à la commande, citée dans mon post, le précise tout simplement :

      Filesystem at /dev/mapper/vg00-lvsys03 is mounted on /var; on-line resizing required
      Performing an on-line resize of /dev/mapper/vg00-lvsys03 to 1048576 (4k) blocks.


      Quant à la solution de couper tous les services en passant en run level 1, et à démonter tranquillement le fs, c'est justement pour éviter cela que j'ai longtemps utilisé ReiserFS avec lequel je n'ai *jamais* eu de problème de retaillage à chaud, même sur des fs avec de nombreuses écritures. Là je voulais voir ce que ça donnait avec ext3...

      Ah, sinon je ne l'ai pas précisé, mais j'ai effectuée cette opération sur une machine de test, hors production, et sans aucune criticité évidemment. Je vais donc aller la voir sans me précipiter :)

    • [^] # Re: À chaud pas trop recommandé.

      Posté par  (Mastodon) . Évalué à 3.

      et on repasse en niveau de production (3, 4 ou 5 etc.)

      3, 4 ou 5 etc ... 6 ?
      ha non , ça c'est pour un autre système souvent en prod lui aussi :p

  • # screen

    Posté par  . Évalué à 3.

    C'est un peu tard pour ton cas, mais quand on fait à distance des opérations un peu risquées et qui peuvent durer il faut toujours le faire dans un screen.
    Comme ça pas de risque que l'opération (critique dans ton cas) soit interrompue par une perte de réseau, on peut soi-même se déconnecter pour laisser tourner le truc sur le serveur ou ouvrir d'autres terminaux en parallèle (dans le même screen ou dans d'autres) pour surveiller l'état du système.

    Dans ton cas, puisque tu es connecté en ssh, tu peux au moins ouvrir une nouvelle connection ssh pour surveiler la charge du système (en particulier les IO) pour voir s'il avance.

    • [^] # Re: screen

      Posté par  (site web personnel) . Évalué à 2.

      Comme je l'ai dit dans mon post : Ma connexion SSH est toujours là (quand j'appuie sur 'entrée', j'ai bien des retours chariots), mais je ne peux pas en ouvrir une autre (je reste en attente après la saisie du mot de passe). Et ce matin, je n'ai plus de connexion du tout, donc screen ou pas, je vais devoir aller voir (mais je reconnais que screen est une bonne habitude sur les opérations longues)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.