web-dev-qa-db-fra.com

Ext4FS accidentellement redimensionné au-dessus de 16 To, comment revenir en arrière?

Nous avons essayé d'augmenter la taille de notre partition de 15 To avec lvresize avec la commande suivante:

lvresize --resizefs --size +1T /dev/vg0/mm

Aucune erreur n'a été affichée pendant l'opération, mais le résultat a été une sorte de catastrophe. Aucun fichier n'était plus visible et l'ensemble du lecteur semblait être vide.

syslog contenait les erreurs suivantes:

inode #2: block 31777: comm ls: bad entry in directory: inode out of bounds - offset=0(0), inode=2, rec_len=12, name_len=1

Nous avons réussi à umount la partition et le plan était d'exécuter fsck pour y remédier:

$ fsck.ext4 -n /dev/mapper/vg0-mm
e2fsck 1.42.9 (4-Feb-2014)
Superblock has an invalid journal (inode 8).
Clear? no

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/mapper/vg0-mm

/dev/mapper/vg0-mm: ********** WARNING: Filesystem still has errors **********

$ fsck.ext4 -v /dev/mapper/vg0-mm
e2fsck 1.42.9 (4-Feb-2014)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***

Corruption found in superblock.  (inodes_count = 0).

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
     or
         e2fsck -b 32768 <device>

/dev/mapper/vg0-mm: ***** FILE SYSTEM WAS MODIFIED *****

Ok, ensuite essayons de lister les superblocs alternatifs disponibles:

$ mke2fs -n  /dev/mapper/vg0-mm
mke2fs 1.42.9 (4-Feb-2014)
mke2fs: Size of device (0x100000000 blocks) /dev/mapper/vg0-mm too big to be expressed in 32 bits using a blocksize of 4096.

Il semble donc que nous ayons réussi à dépasser accidentellement la limite de 16 To avec lvresize et que notre ext4fs ne disposait pas de l'indicateur de fonctionnalité 64 bits activé.

Après cela, nous avons essayé de ramener la taille au-dessous de la limite de 16 To, mais resize2fs ne fonctionne pas non plus, car il pense que la partition est (évidemment) sale et ne veut rien en faire.

Des recommandations quelle direction prendre ensuite? Exécuter le redimensionnement avec force ou essayer d'activer l'indicateur de fonctionnalité 64 bits? Autre chose?

dumpe2fs affiche ceci (parmi d'autres informations):

Inode count: 0
Block count: 4294967295
Block size: 4096

Informations de version pertinentes:

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
e2fsprogs version: 1.42.9-3ubuntu1.3 AMD64
Kernel version: 3.13.0-147-generic

MISE À JOUR: Après avoir lu un code source, nous avons trouvé la cause première du problème: https://github.com/torvalds/linux/commit/4f2f76f751433908364ccff82f437a57d0e6e9b7

La question demeure, comment récupérer de la situation où le nombre d'inodes a été réinitialisé à 0, grâce au bogue de débordement.

partitioningfilesystemlvmext4
2
Matti K

Il semble que le comportement étrange vis-à-vis de lvresize utilisant l’option --resizefs avec le système de fichiers ext et le dernier octet complet 16 16TB grande partition a déjà été vu en 2009: ( https://www.redhat.com/archives/ext3-users/2009-January/msg00003.html )

"Nous devrions probablement faire en sorte que mkfs élimine silencieusement un bloc s'il rencontre une condition aux limites telle que celle-ci ..."

Le générique de fin?

Nous avons pu réparer la situation en piratant le superbloc à la main. Nous avons d’abord pris un instantané LVM de la situation de départ. Ensuite, nous avons vidé les 64 premiers octets de la partition dans un fichier pour un examen plus approfondi. Les valeurs du nombre d'inodes et du nombre de blocs au tout début du superbloc ont été corrompues en raison du bogue répertorié ci-dessus. ( https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout )

Selon l’étude du code source e2fsprogs, nous avons déterminé qu’en écrivant les valeurs Inode Count et Block Count un groupe de blocs plus petit (32 Ko) du maximum sur le superbloc pourrait être une bonne chose à essayer et que cela fonctionne. Les octets étaient

00 80 ff ff 00 80 ff ff

et nous les avons juste dd'ed à la partition.

Avec la dernière version de fsck auto-compilé par e2fsprogs, le reste des erreurs a pu être corrigé. Tout semble bien maintenant.

1
matikka