Ok. Quelque chose me dérangeait à propos de votre problème, alors j’ai allumé une VM pour lui expliquer le comportement auquel il fallait s’attendre. J'arriverai à ce qui m'ennuyait dans une minute; laissez-moi d'abord dire ceci:
Sauvegardez ces lecteurs avant de tenter quoi que ce soit!
Vous avez peut-être déjà fait plus de dégâts que ce que la resynchronisation a fait; pouvez-vous préciser ce que vous vouliez dire quand vous avez dit:
Selon les suggestions, j'ai nettoyé les superblocs et recréé le tableau avec l'option --assume-clean, mais sans aucune chance.
Si vous avez couru un mdadm --misc --zero-superblock, alors ça devrait aller.
Quoi qu’il en soit, récupérez de nouveaux disques et prenez-en des images exactes avant de faire quoi que ce soit qui pourrait écrire davantage sur ces disques.
dd if=/dev/sdd of=/path/to/store/sdd.img
Cela étant dit, il semble que les données stockées sur ces objets soient extrêmement résistantes aux resynchronisations fantaisistes. Continuez à lire, il y a de l'espoir, et c'est peut-être le jour où j'atteins la limite de longueur de réponse.
Le meilleur scénario
J'ai jeté ensemble une VM pour recréer votre scénario. Les disques ne font que 100 Mo, je ne serais donc pas en attente de chaque resynchronisation, mais cela devrait être une représentation assez précise sinon.
Construit le tableau de manière aussi générique et par défaut que possible - morceaux de 512 Ko, disposition symétrique à gauche, disques dans l'ordre des lettres .. rien de spécial.
root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Jusqu'ici tout va bien; faisons un système de fichiers et mettons quelques données dessus.
root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
D'accord. Nous avons un système de fichiers et des données ("données" datafile, et 5 Mo de données aléatoires contenant cette valeur de hachage SHA1 randomdata); Voyons ce qui se passe quand on recrée.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
La resynchronisation s'est terminée très rapidement avec ces minuscules disques, mais cela s'est produit. Alors voici ce qui m'ennuyait de plus tôt; votre fdisk -lsortie. N'avoir aucune table de partition sur le mdpériphérique n'est pas un problème du tout, c'est prévu. Votre système de fichiers réside directement sur le faux périphérique de bloc sans table de partition.
root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
Oui, pas de table de partition. Mais...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Système de fichiers parfaitement valide, après une resynchronisation. Donc c'est bien; vérifions nos fichiers de données:
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Solide - pas de corruption de données du tout! Mais ceci est avec exactement les mêmes paramètres, donc rien n'a été mappé différemment entre les deux groupes RAID. Laissons tomber cette chose avant d'essayer de la casser.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
Prendre du recul
Avant de tenter de résoudre ce problème, voyons pourquoi il est difficile de rompre. RAID 5 fonctionne en utilisant un bloc de parité qui protège une zone de la même taille que le bloc de chaque disque de la matrice. La parité ne concerne pas seulement un disque spécifique, elle est pivotée uniformément sur les disques pour mieux répartir la charge de lecture sur les disques en fonctionnement normal.
L'opération XOR pour calculer la parité ressemble à ceci:
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
Ainsi, la parité est répartie entre les disques.
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
Une resynchronisation est généralement effectuée lors du remplacement d'un disque mort ou manquant. Cela est également fait mdadm createpour s'assurer que les données sur les disques s'alignent avec ce à quoi la géométrie du RAID est supposée ressembler. Dans ce cas, le dernier disque de la spécification de matrice est celui sur lequel la synchronisation est effectuée: toutes les données existantes sur les autres disques sont utilisées pour la synchronisation.
Ainsi, toutes les données du "nouveau" disque sont effacées et reconstruites; soit en construisant de nouveaux blocs de données à partir de blocs de parité pour ce qui aurait dû être là, soit en créant de nouveaux blocs de parité.
Ce qui est bien, c’est que la procédure à suivre pour ces deux choses est exactement la même: une opération XOR sur les données du reste des disques. Le processus de resynchronisation dans ce cas peut avoir dans sa présentation qu’un bloc donné doit être un bloc de parité et penser qu’il construit un nouveau bloc de parité alors qu’il recrée en fait un ancien bloc de données. Donc même s'il pense que cela construit ceci:
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
... il peut simplement s'agir de reconstruire à DISK5partir de la mise en page ci-dessus.
Il est donc possible que les données restent cohérentes même si la matrice est mal construite.
Lancer un singe dans les travaux
(pas une clé; le singe entier)
Test 1:
Faisons le tableau dans le mauvais ordre! sdc, alors sdd, alors sdb..
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Ok, tout va bien. Avons-nous un système de fichiers?
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Nan! Pourquoi donc? Parce que même si toutes les données sont là, elles sont dans le mauvais ordre; ce qui était autrefois 512 Ko de A, puis 512 Ko de B, A, B, etc. a maintenant été mélangé à B, A, B, A. Le disque ressemble maintenant à un charabia pour le vérificateur de système de fichiers, il ne fonctionnera pas. La sortie de mdadm --misc -D /dev/md1nous donne plus de détails; Cela ressemble à ceci:
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 17 2 active sync /dev/sdb1
Quand cela devrait ressembler à ceci:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
Donc, tout va bien. Nous avons écrasé tout un tas de blocs de données avec de nouveaux blocs de parité. Recréez, dans le bon ordre maintenant:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Bien, il y a encore un système de fichiers! Vous avez encore des données?
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Succès!
Test 2
Ok, changeons la taille du bloc et voyons si cela nous cause des problèmes.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Ouais, ouais, c'est arrosé quand ça se passe comme ça. Mais pouvons-nous récupérer?
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Le succès, encore!
Test 3
C’est celui qui, à mon avis, tuerait les données à coup sûr. Faisons un algorithme de présentation différent!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Effrayant et mauvais - il pense avoir trouvé quelque chose et veut faire des réparations! Ctrl+ C!
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
Ok, la crise évitée. Voyons si les données sont toujours intactes après la resynchronisation avec une mise en page incorrecte:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Succès!
Test 4
Montrons simplement que la réduction à zéro des superblocs n'est pas préjudiciable très rapidement:
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Ouais, pas grave.
Test 5
Jetons tout ce que nous avons à faire. Les 4 tests précédents, combinés.
- Mauvais ordre d'appareil
- Mauvaise taille de morceau
- Mauvais algorithme de mise en page
- Superblocs mis à zéro (nous le ferons entre les deux créations)
En avant!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
Le verdict?
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sensationnel.
Il semble donc qu'aucune de ces actions n'a corrompu les données. J'ai été assez surpris par ce résultat, franchement; Je m'attendais à une probabilité modérée de perte de données lors du changement de taille de bloc et à une perte certaine lors du changement de présentation. J'ai appris quelque chose aujourd'hui.
Alors .. Comment puis-je obtenir mes données?
Autant d'informations que vous avez sur l'ancien système vous seraient extrêmement utiles. Si vous connaissez le type de système de fichiers, si vous disposez d'anciennes copies de vos /proc/mdstatinformations avec l'ordre du lecteur, l'algorithme, la taille de bloc et la version des métadonnées. Avez-vous configuré les alertes par e-mail de mdadm? Si c'est le cas, trouvez-en un ancien. sinon, vérifiez /var/spool/mail/root. Vérifiez votre ~/.bash_historypour voir si votre construction d'origine est là-bas.
Alors, la liste des choses que vous devriez faire:
- Sauvegardez les disques avec
ddavant de faire quoi que ce soit !!
- Essayez avec
fsckle md actif actuel - vous venez peut-être de construire dans le même ordre que précédemment. Si vous connaissez le type de système de fichiers, c'est utile. utiliser cet fsckoutil spécifique . Si l'un des outils propose de réparer quoi que ce soit, ne le laissez pas sauf si vous êtes certain d'avoir trouvé le système de fichiers valide! Si une fsckoffre de réparer quelque chose pour vous, n'hésitez pas à laisser un commentaire pour demander si cela aide réellement ou juste sur des données nucléaires.
- Essayez de construire le tableau avec différents paramètres. Si vous avez un vieux
/proc/mdstat, alors vous pouvez simplement imiter ce qu'il montre; sinon, vous êtes un peu dans le noir - il est raisonnable d'essayer tous les différents ordres de lecteurs, mais il est inutile de vérifier chaque taille de bloc possible avec chaque ordre possible. Pour chacun, fsckvoir si vous avez quelque chose de prometteur.
Alors c'est ça. Désolé pour le roman, n'hésitez pas à laisser un commentaire si vous avez des questions et bonne chance!
note de bas de page: moins de 22 000 caractères; 8k + timide de la limite de longueur