Ce qui m’entonne comment le serveur a pu marché pendant longtemps comme ça et d’un seul cout il a un problème file-système, j’ai l’impression, ça arrive à chaque fois quant le disque est presque 80% d’utilisation, c’est pour ça je pense que le problème vient aussi du disque.
C’est exactement ce que j’écrivais. C’est à ce moment que le système de fichiers va essayer d’utiliser les blocs situés au-delà de la fin de l’ensemble RAID. Inutile de tourner autour du pot : il faut réparer cette incohérence de tailles.
Je vous remercie pour réponses !
J’ai déjà mentionné ça à l’hébergeur même quant il ont mis deux disques de taille différentes dans un raid1 et ils ont dit qu’ils ont l’habitude et pas de problème (et j’avoue moi je ne suis pas trop à l’aise pour la résolution des problèmes de disques 
).
Historiquement le serveur avait deux disque 256Go, puis deux de taille différentes (500Go et 256Go) et il a resté en marche pendant un bon moment puis le disque de 256Go tombait en panne et il est remplacé par un de 500Go (maintenant deux disques de 500Go) mais sans changement de partitionnement (car à chaque fois on appliquait la table de partition existante sur le nouveau avant de reconstruire le raid ), c’est pour cela le serveur se retrouve avec les partitions :
- sda1 (sdb1) -> md0
- sda2 (sdb2) : swap -> md2
- sda3 , sdb3 -> md1 ( Array Size : 243069568 (231.81 GiB 248.90 GB))
- Le reste du disque non partitionné
Les résultats des commandes “mdadm --examine /dev/sda3”, “mdadm --examine /dev/sdb3” et “mdadm --detail /dev/md1” (cf. résultat ci-dessus), montre que Used Dev Size et Array Size ont les mêmes valeurs pour les sda3, sdb3 et aussi pour md1 qui les groupe. donc, sauf erreur, malgré ce problème de taille je ne comprends pas pourquoi le serveur essaye décrire au-delà du la taille limite d’un seul cout même s’il reste encore plus de 40Go libre, vu que la partition raid (md1) a la même limite que la limite des deux partitions sda3 et sdb3.
Pour moi il y a deux problèmes :
- problème de taille : soft
- problème de disque : hard (d’après les résultat de test smart)
Et dans tous les cas il faut changer de disque (le serveur marche à l’état actuel en mode dégradé ( pic de charge cpu) et avec l’erreur " md1: rw=0, want=486139248, limit=486139136" dans les logs).
Bonjour,
Je dis ça pour ce que ça vaut ; pour l’espace disque, il n’y a peut-être plus assez d’inœuds disponibles.
Semble dire qu’il y en a suffisamment.
Free inodes: 30182458
# df -i
Je suis le sujet car je suis intéressé de voir comment vous allez procéder pour agrandir le RAID (md1)
Le reste suivra naturellement.
Pouvez vous m’aider pour la réparation de cette incohérence, je n’ai pas d’expérience sur le sujet et d’après mes recherches c’est une opération risquée et je flippe un peu vu que c’est un serveur de prod.
Merci beaucoup par avance.
@ r2mi une fois réussi, je mettrai les étapes.
Le changement de disques n’explique pas l’incohérences entre les tailles de l’ensemble RAID et du système de fichiers. Le serveur a vraiment toujours été en RAID ?
Parce que le système de fichiers ext* dit qu’il est plus grand que l’ensemble RAID.
Je vois deux méthodes : la risquée et la longue (et risquée aussi, mais pas de la même façon). Pour la première, il faut quand même que je vérifie avant.
Edit : j’ai fait des essais, et en fait il y a deux méthodes possibles rapides et peu risquées :
- réduire le système de fichiers à la taille de l’ensemble RAID, mais il faut le démonter donc impossible depuis le système si c’est la racine.
- agrandir les partitions puis l’ensemble RAID, faisable lorsqu’il est monté.
Mais comme tu l’as écrit, il faudrait régler le problème du disque défectueux.
En attendant peux-tu poster le résultat des commandes suivantes :
tune2fs -l /dev/md0
cat /proc/swaps
df -hT
Et aussi le contenu du fichier badblocks.txt après avoir exécuté la commande suivante :
badblocks -svo badblocks.txt /dev/sdbLe disque défectueux est remplacé et c’est le moment de la vérité 
je j’avoue je flippe et il faut garder le serveur disponible. Je pense le mieux c’est la deuxième solution et la moins risquée ?
Sauf erreur, je comprends par “/dev/sda3 2252800 488392064 243069632+ 83 Linux” de la sortie “fdisk -l …” (cf. ci-dessous) que la partition “sda3” est limitée par le secteur 488392064 mais le dernier bloc est resté à 243069632 (lié à la limite de /dev/md1 qui est à 243069568 fixée avant par les anciens disques de 256Go) et il faut corriger cette taille de bloc. est ce bien ça ? si oui, pouvez vous m’aider? je regarde de mon coté mais c’est la première fois que je fais de telle opération et un deuxième avis ça rassure? merci d’avance.
A l’état actuel voici l’état des partitions des disques :
1. /dev/sda (qui est toujours dans le raid1)
# fdisk -l /dev/sda (qui est toujours dans le raid1)
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x56c32dd7
Device Boot Start End Blocks Id System
/dev/sda1 * 1 204799 102399+ 83 Linux
/dev/sda2 204800 2252799 1024000 82 Linux swap / Solaris
/dev/sda3 2252800 488392064 243069632+ 83 Linux
# sfdisk -d /dev/sda > sda.out
# cat sda.out
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 1, size= 204799, Id=83, bootable
/dev/sda2 : start= 204800, size= 2048000, Id=82
/dev/sda3 : start= 2252800, size=486139265, Id=83
/dev/sda4 : start= 0, size= 0, Id= 0
2. /dev/sdb (le nouveau disque, pas encore dans le raid1)
J’ai essayé d’appliquer les partitions des “sda” et voici la sortie :
# sfdisk /dev/sdb < sda.out
Checking that no-one is using this disk right now …
OK
Disk /dev/sdb: 60801 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an msdos signature
/dev/sdb: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sdb1 * 1 204799 204799 83 Linux
/dev/sdb2 204800 2252799 2048000 82 Linux swap / Solaris
/dev/sdb3 2252800 488392064 486139265 83 Linux
/dev/sdb4 0 - 0 0 Empty
Warning: partition 1 does not end at a cylinder boundary
Warning: partition 2 does not start at a cylinder boundary
Warning: partition 2 does not end at a cylinder boundary
Warning: partition 3 does not start at a cylinder boundary
Successfully wrote the new partition table
Re-reading the partition table ...
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)Pas exactement.
243069632+ est la taille de la partition en “blocs” de 1 Kio (1024 octets, soit deux secteurs de 512 octets), le + indiquant que c’est un arrondi par défaut, le nombre de secteurs (de 512 octets) de la partition (488392064 - 2252800 + 1 = 486139265 comme l’affiche sfdisk) étant impair.
La taille du système de fichiers n’est pas visible dans la table de partition.
Il faut corriger la taille de la partition, c’est-à-dire la position du secteur de fin de celle-ci. Tu peux en profiter pour utiliser tout l’espace libre non alloué des disques si tu veux, à moins que tu préfères garder cet espace pour un autre usage.
Mais il y a un mystère que je ne comprends pas : dans tous mes essais, le noyau refuse de monter un système de fichiers ext* dont la taille déclarée dépasse la taille de son contenant.
Je m’inquiète @yfi … Je crains qu’il y ait eu un problème.
@PascalHambourg, pourquoi cette mention ?
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes:
dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
Quelle est l’utilité de cette commande ? Il faudra bien installer Grub sur le nouveau sdb ?
Et aussi :
C’est pas important ? On peut l’ignorer ? Ça implique quoi ?
Elle a bien été corrigée par la duplication du schéma de partitionnement ?
édition : ça ne change en rien le contenant RAID md1 demeurant plus petit que les partitions sda3 / sdb3.
Je ne vois pas vraiment comment agrandir sda3 et sdb3 avec le système en fonctionnement…
Pour ça, il faut bien que le nouveau disque sdb ait exactement la même taille que sda ?
Suffit pour indiquer que les deux disques ont des capacités identiques ?
.
J’ai bien lu que @yfi n’était pas assuré pour faire les manipulations et j’ai peur pour lui et le serveur en production.
Pourvu que les choses se passent bien.
J’essaie de suivre.
Merci pour vous deux, malheureusement je n’ai rien fait pour le moment, je suis un peu chargé, le serveur est en mode dégradé, marche avec charge CPU élevée.
Il y a eu le changement de disque sdb (500G, même taille que sda) et j’ai reconstruit le raid. le disque est en mode lecture/écriture mais il me reste à corriger la taille.
Dans les logs de karnel il y a les warnings ci-dessous qui recommandent de faire e2fsck mais je ne sais pas si ça ferra quelque chose vu que j’ai déjà passé cette commande avant changement de disque et elle n’a pas réglé le problème et l’erreur suivante persiste :
kernel: [140621.072462] attempt to access beyond end of device
kernel: [140621.076419] md1: rw=0, want=486139248, limit=486139136
Erreur kernel :
[ 10.175284] Adding 1023420k swap on /dev/md2. Priority:-1 extents:1 across:1023420k
[ 10.191655] EXT3-fs (md1): warning: mounting fs with errors, running e2fsck is recommended
[ 10.205392] EXT3-fs (md1): using internal journal
[ 11.842170] EXT2-fs (md0): warning: mounting unchecked fs, running e2fsck is recommended
Cela efface le secteur d’amorce de la partition, mais franchement, je ne sais même pas ce qu’est une “partition DOS”. Partition FAT ? Partition FAT contenant un système MS-DOS ? Partition d’un disque partitionné au format DOS ?
Le secteur d’amorce d’une partition FAT contient en outre des méta-données sur le système de fichiers FAT, mais je ne vois pas pourquoi en faire un cas particulier.
Dans le MBR de /dev/sdb, pas dans le secteur d’amorce d’une des partitions.
Pas important. On peut l’ignorer. L’alignement en cylindres est obsolète.
Non puisque la taille des partitions et ensembles RAID n’a pas changé.
En effet.
Les agrandir ne pose pas de problème même si elles sont utilisées (les réduire, en revanche…). Avec parted (ou {c|s}fdisk + partprobe), on peut à la fois modifier la table de partition et faire prendre en compte ces modifications par le noyau sans redémarrer.
Par contre il est impératif d’agrandir l’ensemble RAID immédiatement après sans redémarrer, car les superblocs RAID 0.90 qui sont normalement situés à la fin des partitions ne seraient plus à la fin, et si le système était redémarré avant, l’ensemble RAID ne serait plus reconnu.
Non, pas nécessairement. L’ensemble RAID sera agrandi en fonction de la plus petite partition membre.
Tu veux dire que les partitions du nouveau disque ont été intégrées aux ensembles RAID qui sont à nouveau complets (donc pas dégradés) ? C’est une bonne chose. A vérifier dans /proc/mdstat.
fsck ne règlera pas le problème de la taille.
Par contre je vois que les messages sont produits par les pilotes ext2 et ext3. Or depuis le noyau de Jessie (Debian 8), ces pilotes ne sont plus présents et c’est le pilote ext4 qui gère aussi les systèmes de fichiers ext2 et ext3, et refuse de monter un système de fichier qui se déclare plus grand que son contenant. Cela pourrait expliquer pourquoi ton serveur parvient à le monter malgré tout.
Quelle est la version de Debian installée sur ce serveur, et quel est le noyau actif ? S’agit-il d’une version antérieure à Jessie, comme Wheezy (Debian 7) avec un noyau 3.2 ?
lsb_release -a
uname -a
Cette information peut être importante pour tester si la procédure pour agrandir l’ensemble RAID est applicable à cette version.
Oui, et le serveur marche :
$ cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb2[2] sda2[1]
1023424 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[1] sda1[0]
102272 blocks [2/2] [UU]
md1 : active raid1 sdb3[1] sda3[0]
243069568 blocks [2/2] [UU]
suivi de resize2fs ?
Effectivement, le serveur est debian7 avec le noyau v3.2. et le serveur a pu démarré et monter le fs.
et merci bcp pour ta remarque, elle est importante car je dois migrer vers debian8 dans les jours qui viennes. donc il faut absolument corriger la taille du raid avant migration.
Avez vous la procédure pour correction de la taille de file système du raid (sans augmenter les partitions sda3 et sdb3, je n’ai pas vraiment besoin de plus de taille en disque) ?
merci encore.
Il faut que je teste ma procédure sur Wheezy (pas avant ce soir), car si elle ne fonctionne pas jusqu’au bout, le système ne pourra plus démarrer.
Sinon, il y a la méthode longue :
- retirer une des deux partitions de l’ensemble RAID
- agrandir la partition
- réintégrer la partition dans l’ensemble RAID
- attendre la fin de la resynchronisation
- recommencer avec l’autre partition
La suite de la procédure est commune aux deux méthodes :
- agrandir l’ensemble RAID
- agrandir le système de fichiers
Il faudrait aussi vérifier si les deux autres ensembles RAID n’ont pas le même défaut qui serait passé inaperçu jusqu’ici. J’avais demandé la sortie des commandes suivantes, je ne crois pas l’avoir vue :
tune2fs -l /dev/md0
cat /proc/swaps
df -hT# tune2fs -l /dev/md0
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: fc246c90-3f2d-4c2a-b726-58d0eb5406f2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 25688
Block count: 102396
Reserved block count: 5119
Free blocks: 38732
Free inodes: 25630
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1976
Inode blocks per group: 247
Filesystem created: Fri Feb 1 18:16:28 2013
Last mount time: Fri Feb 1 20:34:05 2013
Last write time: Thu Sep 27 09:53:19 2018
Mount count: 29
Maximum mount count: 30
Last checked: Fri Feb 1 18:16:28 2013
Check interval: 15552000 (6 months)
Next check after: Wed Jul 31 19:16:28 2013
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: da20b55e-76de-49f5-898d-807ac3b89ff9
tune2fs -l /dev/md1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 0f2b6dc0-2821-437f-8954-4c280e5143a3
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 30392320
Block count: 60767408
Reserved block count: 3038370
Free blocks: 35740913
Free inodes: 30187009
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Fri Feb 1 18:16:29 2013
Last mount time: Thu Sep 27 01:17:15 2018
Last write time: Fri Sep 21 14:28:53 2018
Mount count: 4
Maximum mount count: 28
Last checked: Fri Sep 21 14:21:05 2018
Check interval: 15552000 (6 months)
Next check after: Wed Mar 20 13:21:05 2019
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 12746773
Default directory hash: tea
Directory Hash Seed: fac808b4-2d04-4cad-9e56-c3798b242883
Journal backup: inode blocks
# cat /proc/swaps
Filename Type Size Used Priority
/dev/md2 partition 1023420 21160 -1
# df -hT
Sys. fich. Type Taille Util. Dispo Uti% Monté sur
rootfs rootfs 229G 91G 127G 42% /
udev devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 801M 220K 801M 1% /run
/dev/md1 ext3 229G 91G 127G 42% /
tmpfs tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs tmpfs 4,0G 0 4,0G 0% /dev/shm
none tmpfs 4,0G 0 4,0G 0% /dev/shm
/dev/md0 ext2 97M 59M 33M 65% /boot
comment peut-on interpréter :
Filesystem features : .....
La ligne “filesystem features” liste les fonctionnalités actives du système de fichiers. Leur description se trouve dans la page de manuel ext2, ext3 ou ext4.
Comme je le craignais, la taille définie dans le système de fichiers ext2 de /dev/md0 (102396 Kio) qui est monté sur /boot est supérieure à la taille du volume /dev/md0 (102272 Kio). Comme avec /dev/md1, elle est presque égale à la taille des partitions sous-jacentes /dev/sda1 et /dev/sdb1 (102399 Kio). Le même problème pourrait donc se produire en cas d’ajout de fichiers dans /boot, typiquement avec l’installation d’un nouveau noyau lors de la migration vers Jessie (environ +15 Mo).
Par contre la taille du swap dans /dev/md2 (1023420 Kio) est inférieure à la taille de /dev/md2 (1024000 Kio).
En l’état, on ne peut pas agrandir /dev/md0 car il n’y a pas d’espace libre sur les disques entre les partitions sd[ab]1 et sd[ab]2 pour les agrandir. Ou bien il faudrait réduire le swap en recréant les partitions sd[ab]2 une par une pour placer leur début un peu plus loin. L’autre solution tire parti de la possibilité de démonter /boot dont le contenu n’est pas utile pour le fonctionnement courant du système. Une fois le système de fichiers démonté, il serait possible de le réduire à la taille de l’ensemble RAID. Mais avant il faut que je vérifie si ça fonctionne sous Wheezy car dans mes souvenirs il me semble que ça ne fonctionnait pas.
Autre problématique liée à /boot : le chargeur d’amorçage. Sais-tu quel est le chargeur d’amorçage installé ? GRUB 1, GRUB 2 ou LILO ?
Les partitions sd[ab]1 commencent au secteur 1 donc il n’y a aucun espace libre entre le MBR et elles pour l’embarquage de GRUB 2. Or il me semble que GRUB 2 exige l’embarquage lorsque /boot est en RAID. Cela l’exclut a priori. Reste GRUB 1 (obsolète) ou LILO. Que ce soit l’un ou l’autre, il faudrait impérativement le réinstaller après toute manipulation sur md0.
J’ai fait des tests avec le dernier système Wheezy qui me reste.
-
Je confirme que les pilotes ext2 et ext3 du noyau 3.2 de Debian 7/Wheezy acceptent de monter un système de fichiers plus grand que le périphérique de stockage qui le contient, contrairement au pilote ext4 du noyau 3.16 de Debian 8/Jessie.
-
Je confirme également que le message du noyau "
attempt to access beyond end of device" rapporté dans ton message initial se produit lorsqu’on remplit le système de fichiers à fond. -
Mauvaise nouvelle : la version du gestionnaire de partitions
partedincluse dans Debian 7 ne permet pas d’agrandir une partition. Sa commande “resize” est buggée et a été remplacée par la commande “resizepart” dans les versions suivantes. Il faudra donc utiliser{|c|f|s}diskpour supprimer et recréer la partition avec les mêmes numéro et secteur de début. -
Autre mauvaise nouvelle : contrairement à Debian 8, il n’est pas possible de faire prendre en compte le changement de taille d’une partition en cours d’utilisation. C’est peut-être dû au fait que le redimensionnement via
parted(qui informe le noyau du changement de taille) n’étant pas possible, j’ai utilisépartprobepour informer le noyau des changements de partitions. Je n’ai pas testé plus en détail. La conséquence est que la méthode rapide que j’avais testée avec succès sur Debian 8 n’est pas applicable. Il faudra donc appliquer la méthode longue décrite dans mon message n° 25. -
En revanche la réduction d’un système de fichiers ext2 trop grand non monté a fonctionné comme avec Debian 8. Cela peut servir pour /dev/md0 utilisé comme /boot. Cependant je n’y toucherais pas avant d’avoir fait le point sur le chargeur d’amorçage, au risque de casser l’amorçage.
Voici ma procédure pour agrandir /dev/md1, en espérant n’avoir pas fait d’erreur ni d’oubli.
1° Installer le paquet parted s’il ne l’est pas déjà :
apt-get install parted
2° Agrandir la partition /dev/sdb3 d’au moins 256 secteurs
Retirer la partition /dev/sdb3 de l’ensemble RAID /dev/md1 :
mdadm --fail /dev/md1 /dev/sdb3
mdadm --remove /dev/md1 /dev/sdb3
Si tu ne l’as pas conservé, recréer le fichier dump de la table de partition sda.out précédemment créé par :
sfdisk -d /dev/sda > sda.out
(ou sdb, peu importe, les tables de partition sont identiques)
Editer le fichier sda.out.
Augmenter la taille de la partition n° 3 à au moins 486139265+256=486139521.
Fichier original :
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 1, size= 204799, Id=83, bootable
/dev/sda2 : start= 204800, size= 2048000, Id=82
/dev/sda3 : start= 2252800, size=486139265, Id=83
/dev/sda4 : start= 0, size= 0, Id= 0
Fichier modifié :
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 1, size= 204799, Id=83, bootable
/dev/sda2 : start= 204800, size= 2048000, Id=82
/dev/sda3 : start= 2252800, size=486139521, Id=83
/dev/sda4 : start= 0, size= 0, Id= 0
Appliquer le fichier modifié au disque /dev/sdb :
sfdisk /dev/sdb < sda.out
Si tu préfères utiliser fdisk, cfdisk ou parted interactivement à la place de sfdisk :
- supprimer la partition n° 3
- recréer la partition n° 3 avec le même secteur de début 2252800 et un secteur de fin au moins 256 plus loin qu’initialement (488392064+256=488392320)
- type de partition : primaire
- numéro de partition : 3
- secteur de début : 2252800
- secteur de fin : 488392320 ou plus
- identifiant de type : 83 (Linux)
- écrire les changements sur le disque et quitter.
Un message d’erreur disant que le noyau n’a pas pu prendre en compte la nouvelle table de partition parce que le disque est en cours d’utilisation est normal. Dans ce cas, informer le noyau du changement de taille par une autre méthode :
partprobe /dev/sdb
Ajouter la partition /dev/sdb3 à l’ensemble RAID /dev/md1 :
mdadm --add /dev/md1 /dev/sdb3
Attendre la fin de la synchronisation dans /proc/mdstat.
3° Agrandir la partition /dev/sda3
Retirer la partition /dev/sda3 de l’ensemble RAID /dev/md1 :
mdadm --fail /dev/md1 /dev/sda3
mdadm --remove /dev/md1 /dev/sda3
Appliquer le fichier de table de partition modifié au disque /dev/sda (ou utiliser fdisk, cfdisk…) :
sfdisk /dev/sda < sda.out
Informer le noyau du changement de taille :
partprobe /dev/sda
Ajouter la partition /dev/sda3 à l’ensemble RAID /dev/md1 :
mdadm --add /dev/md1 /dev/sda3
Attendre la fin de la synchronisation dans /proc/mdstat
4° Agrandir l’ensemble RAID :
mdadm --grow /dev/md1 --size=max
5° Agrandir le système de fichiers ext3 dans /dev/md1 en ligne :
resize2fs /dev/md1
Note : Avant et après l’agrandissement de chaque partition (+partprobe) et de l’ensemble RAID, on peut vérifier que la nouvelle taille est bien prise en compte en affichant le contenu de /proc/partitions ou avec la commande lsblk -b.
1 J'aime
J’ai lu attentivement 4 fois avant ma sieste et de nouveau 3 fois maintenant ;
je ne vois rien qui ne va pas, c’est clair et parfaitement compréhensible.
Je n’aurai pas su trouver la valeur minimale de 256 secteurs à ajouter.
J’ajoute une répétition : ne pas redémarrer de toute la procédure de 1° à 5° accomplie.
@PascalHambourg, je te remercie infiniment, c’est vraiment claire.
J’ai juste une question, 512 c’est la taille d’un secteur, pourquoi 256 minimum ? moi j’ai cru qu’il faut ajouter au minimum la taille d’un secteur ou un multiple d’un secteur ?