resize2fs / ext4 bloqué et 100% cpu

Support Debian
#1

Salut,

Pour pouvoir transférer mon système depuis mon vieux disque (500GB dont seulement 30 utilisés) vers un autre (160GB), j’utilise la toute dernière version stable de Clonezilla (1.2.11-23-amd64 du 25/11/2011).

Comme il est impossible de restaurer l’image d’une partition donnée sur un disque plus petit (ce qui est logique), j’ai entrepris de diminuer la taille de ma grosse partition (ext4).
C’est là que ça se corse : resize2fs semble fonctionner pendant un moment (disque qui tourne, utilisation raisonnable du CPU) mais à un certain point il se bloque sans raison apparente ni message d’erreur (le disque s’arrête de tourner, CPU à 100%).
Après une bonne demi-heure dans cet état je l’ai arrêté ^C, inutile de dire que e2fsck ne rattrape absolument pas les erreurs du filesystem suite à cet arrêt brutal…

J’ai essayé à la fois avec et sans journal (après avoir remis les données d’origine), même résultat, du coup je manque un peu d’idées.
Une recherche sur le net ne donne rien de probant par rapport à ce problème.

Sur Clonezilla :

  • e2fsprogs 1.42-WIP (20/11/2011)
  • kernel 3.1.0-1-amd64

Sur ma Debian, kernel 3.2.1-2 (des fois que ça joue).

Partant de là :

  • une idée de comment contourner ce qui me semble être un bug ?
  • le cas échéant, comment cloner mon système sur ce nouveau disque plus petit sans passer par resize2fs ?
#2

Salut,

partitions / et /home séparées ?

#3

Foutu pour foutu, si tu ne tiens pas particulièrement aux données stockées, tu peux essayer de combattre le mal par le mal : remettre un coup de resize sur la partition en vrac avant de lui appliquer un fsck.

Pour reproduire le système, une simple copie des données utiles (cp -rp).
Ajuste /etc/fstab du système en rapport avec le nouveau disque qui l’accueille,
redéfinis les interfaces réseau (/etc/network/interfaces, /etc/udev/rules.d/70-persistent-net.rules), autres détails comme /etc/X11/xorg.conf, un nouveau nom /etc/hostname…
Enfin, si le disque n’est pas pourvu de chargeur d’amorçage, installes-en un.

#4

@loreleil : Sur le disque concerné (sda) il n’y a que la partition / et le swap. Le reste (/home et mon /data) sont sur d’autres disques.
Le but du déplacement est double : profiter du SSD 160GB pour le système, et libérer le disque de 500GB pour le mettre ailleurs.

@etxeberrizahar : Heureusement mes données d’origine sont en lieu sûr (j’ai fait une image complète avant de toucher à quoi que ce soit, je me suis trop souvent fait avoir :mrgreen:), d’ailleurs là je suis revenu sur la machine concernée (plantage avec journal -> restauration -> plantage sans journal -> restauration).

J’ai bien pensé à faire quelque chose dans ce goût là, mais comme c’est ma partition système ça va pas le faire du tout si des fichiers sont corrompus… Ce que j’ai peur c’est que le deuxième appel de resize2fs passe des erreurs sous silence et me bousille/perde des fichiers (sans que fsck puisse forcément le détecter), avec un système instable à la clé.

C’est aussi bête que ça ? Pas de risques de trucs bizarres avec des fichiers spéciaux qui traîneraient dans /dev, /proc etc ? (sachant bien sûr que je ferai ça à partir du Clonezilla Live)
Sinon pour la config y’a quasiment rien qui changera à part le fstab (UUIDs et options de montage de /) puisque le nouveau disque va remplacer l’autre (après je ferai les ajustements nécessaires à un SSD mais c’est une autre question).

#5

Une inspiration, peut être …

isalo.org/wiki.debian-fr/ind … tion=purge

recreer-un-os-depuis-une-sauvegarde-home-separee-t35283.html

la suite en cours de rédaction … :083

#6

Merci, j’étudierai ça à tête reposée pendant la semaine. J’ai besoin de ma machine toute la semaine donc de toutes façons je vais pas foutre le bazar à cette heure ci. :mrgreen:

#7

tu peux passer par gparted a l’aide d’un live-cd
sysresccd.org/Download
tu eux cloner d’un disque a l’autre ou redimentioner les donnée ou les 2 :slightly_smiling:

quand cp sa m’étonnerai que sa soie fiable car certain fichier ne son pas lisible… sa peux suffire pour le répertoire utilisateur mai pour le system hum…

#8

Ah oui j’avais complètement oublié GParted. :doh:
Je vais aller regarder ça, avec un peu de chance soit il n’utilise pas resize2fs soit c’est une autre version qui n’a pas ce bug…

#9

Salut,

gparted installé.

Les paquets suivants sont disponibles.

[quote]:~$ acp reiserfsprogs reiser4progs
reiserfsprogs:
Installé : (aucun)
Candidat : 1:3.6.21-1
Table de version :
1:3.6.21-1 0
990 ftp.fr.debian.org/debian/ squeeze/main amd64 Packages
reiser4progs:
Installé : (aucun)
Candidat : 1.0.7-6
Table de version :
1.0.7-6 0
990 ftp.fr.debian.org/debian/ squeeze/main amd64 Packages
:~$
[/quote]

:~$ apt-listbugs list reiserfsprogs reiser4progs Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done critical bugs of reiser4progs (-> ) <marked as done in some version> #632633 - reiser4progs: Casts 64 bit integers to 32 bit, infinite loop in progress bar code (Fixed: reiser4progs/1.0.7-6.1) serious bugs of reiser4progs (-> ) <marked as done in some version> #634683 - packages cannot depend on libreiser4-dev (Fixed: reiser4progs/1.0.7-6.1) Summary: reiser4progs(2 bugs) :~$

:~$ apt-listbugs list e2fsprogs Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done :~$
:think:

#10

Le fait est, tu en conviendras, que c’est pas normal qu’il tourne CPU à fond et sans aucun accès disque pendant plus de 30mn alors qu’il avait bien commencé. :wink:
Entre temps j’ai vu qu’on pouvait lancer resize2fs avec une option de débogage pour voir ce qu’il fait exactement, je vais tenter ça aussi (ça va donner le même résultat mais au moins on saura pourquoi).

#11

Si tu passes par gparted, rebelote pour dd,resize2fs,fsck …
Ce sera long, ce sera lourd, ce sera risqué et tu n’auras pas plus de garantie qu’avec cp.

cp sera plus rapide, plus sûr, plus économique, plus simple et sans danger.
En lui adjoignant -v tu auras la trace des copies, tu sauras le nom du fichier (ou les noms des fichiers) sur le(s)quel(s) la lecture bloque éclaircissant ainsi les circonstances du blocage de resize2fs. À la lumière de cette information tu pourras envisager une reproduction plus rapide en excluant le(s) fichier(s) qui coince(nt).

#12

Pour le moment resize2fs -d 14 /dev/sda1 100G (même commande qu’auparavant, avec uniquement le -d 14 en plus) est entré dans sa phase 100% CPU / pas d’accès disque, mais grâce aux traces de débogage je constate qu’il fait des trucs : le changement correspond au passage du déplacement de blocs au déplacement d’inodes.
Les inodes concernés continuent d’augmenter, je laisse tourner…

(ouais je sais j’avais dit que j’ai besoin de ma machine mais j’ai pas pu m’empêcher, le taf attendra un peu :blush:)

#13

Bon, conclusion de l’affaire : fausse alerte. :doh:

Après quasiment une heure et quart à “tourner dans le vide” (sauf que du coup avec -d 14 je pouvais constater que ce n’était pas le cas en réalité) ça a fini par être bon. Partition supprimée/recréée avec parted, un deuxième resize pour ajuster, fsck entre chaque manip’, tout roule : mon / fait maintenant 110GB, je vais pouvoir le transférer sur l’autre disque dans la soirée.
Morale : faire un resize d’une partition de 500GB, même s’il y a peu de données dessus, c’est long… très long… et l’indicateur d’activité du disque dur n’est PAS un témoin fiable. :angry-banghead:

Merci à tous, et désolé du dérangement. :006

#14

Si le but est de transférer le contenu sur un SSD, ça aurait pu valoir le coup de recréer un système de fichier optimisé pour SSD.

#15

Qu’est-ce à dire ?
De l’ext4 monté avec l’option discard fonctionne tout aussi bien que le reste, je pense. UBIFS etc ne présente aucun avantage particulier car le contrôleur du SSD gère le wear-leveling lui-même, en toute transparence pour l’OS.
Je me plante quelque part ?

Edit : Wikipedia semble d’accord avec moi en tous cas (je sais, c’est pas toujours 100% fiable, mais ça correspond à ce que j’ai lu ailleurs) : en.wikipedia.org/wiki/Solid-sta … le_systems

#16

Taille de bloc, alignement…
Je ne connais pas les détails n’ayant pas encore utilisé de SSD.

#17

Après quelques recherches, sur mon modèle il s’agit de pages de 8KB, avec un erase block size de 256 pages (soit 2MB).
Effectivement il serait peut-être judicieux de faire un filesystem avec des blocs de 8KB (actuellement 4KB) et d’aligner la partition sur 2MB (ça c’est pas le problème, Clonezilla aurait permis de le faire).

Mais pour changer la taille des blocs, si j’ai tout bien suivi la seule solution est de passer par la méthode cp. Ce qui me ramène à ma question précédente : quid des fichiers spéciaux qui peuvent traîner dans /dev /proc etc, ils vont être correctement reproduits ? Je pense notamment à des trucs comme /dev/zero, /dev/random et autres trucs sans fin…

#18

Cette question se pose pour un système démarré avec /tmp, /var, /proc, /sys, des montages tiers…

Rien à craindre si tu démarres sur un live-cd ou un linux tiers pour copier les fichiers du système inerte.

cp -rp /ancien /nouveau

Je peux te certifier que j’ai assez souvent patiqué cette méthode simple de clonage avec réussite.

#19

Il ne faut pas copier les pseudo-fichiers montés sur /proc, /sys… qui sont des structures de données du noyau et pas des vrais fichiers. En fait il ne faut copier que ce qui se trouve sur le système de fichiers, et pas ce qui est sur les points de montages (/dev si en tmpfs géré par udev, /usr si sur une autre partition…). Si tu fais la copie depuis le système donc avec tout monté, l’option -x de cp le permet. Sinon si rien n’est monté sur le système de fichiers à copier, l’option n’est pas nécessaire.

Il faudra ensuite modifier les UUID partout où c’est nécessaire (fstab…) et réinstaller le chargeur d’amorçage sur ne nouveau disque car cp ne le fait pas, une partie du chargeur étant en dehors du système de fichiers.

#20

Ok merci à vous deux, ça paraît plus simple que ce que je m’étais imaginé. Je vous tiens au jus.