Manque de mémoire en exécutant fsck sur les systèmes de fichiers volumineux


13

Je m'occupe d'une vieille boîte Linux Debian (exécutant etch) avec seulement 512 Mo de RAM, mais beaucoup de stockage externe attaché. Un système de fichiers ext3 a une taille de 2,7 To et fsck ne peut pas le vérifier, car il manque de mémoire, avec une erreur comme celle-ci:

   Erreur lors de l'allocation du tableau de blocs d'annuaire: échec de l'allocation de mémoire
   e2fsck: abandonné

J'ai ajouté une partition de swap de 4 Go et elle ne se termine toujours pas, mais il s'agit d'un noyau 32 bits, donc je ne pense pas que l'ajout de plus aidera.

Mis à part le démarrage dans un noyau 64 bits, existe-t-il d'autres moyens pour que fsck termine sa vérification?

Réponses:


12

Un noyau 64 bits et de grandes quantités de RAM permettront au fsck de finir bien et rapidement. Alternativement, il y a maintenant une option dans e2fsck qui lui dira de stocker tous ses résultats intermédiaires dans un répertoire plutôt que dans la RAM, ce qui aide énormément. Créez /etc/e2fsck.confavec le contenu suivant:

[scratch_files]
directory = /var/cache/e2fsck

(Et, bien sûr, assurez-vous que ce répertoire existe et se trouve sur une partition avec quelques Go d'espace libre). e2fsck exécutera SLLOOOOWWWWWWW, mais au moins il se terminera.

Bien sûr, cela ne fonctionnera pas avec la racine FS, mais si vous avez un échange, vous avez quand même passé le montage de la racine FS.


6

J'ai fini par essayer ce que le ventre suggérait; voici quelques détails supplémentaires qui peuvent être utiles si, comme moi, vous n'avez jamais vu cette nouvelle fonctionnalité dans e2fsck auparavant.

L'option de configuration "scratch_files" pour e2fsck est devenue disponible au cours de la période de la version 1.40.x. (Dans notre cas, nous avons dû passer à la dernière distribution Debian pour obtenir cette fonctionnalité.)

En plus de l'option "directory = / var / cache / e2fsk" qui a été suggérée, il existe d'autres options de configuration pour affiner l'utilisation du stockage des fichiers de travail. J'ai utilisé "dirinfo = false", car le système de fichiers avait un grand nombre de fichiers, mais pas un si grand nombre de répertoires. Si la situation était inversée, l'option "icount" serait appropriée. Ces options ont toutes été documentées dans la page de manuel de e2fsck.conf.

BTW, Ted T'so a écrit sur ces options dans ce fil .

J'ai trouvé que e2fsck fonctionnait extrêmement lentement, bien plus que ce que Ted avait prédit. Il fonctionnait à 99,9% d'utilisation du processeur la plupart du temps (sur un ancien processeur extrêmement lent), ce qui suggère que le stockage de ces structures de données sur le disque au lieu de la mémoire n'était pas la principale cause du ralentissement. Il se pourrait que quelque chose d'autre sur ce qui était stocké dans le système de fichiers ait rendu e2fsck particulièrement lent. En fin de compte, j'ai abandonné la vérification du système de fichiers pour l'instant; le système de fichiers devait être vérifié, mais il n'y avait pas d'erreurs (pour autant que je sache), donc je vais m'arranger pour le vérifier à un moment plus pratique lorsque nous pouvons nous permettre d'avoir une interruption d'une semaine.


Je me demande si btrfs est mieux à ça. Les outils ext4 n'étaient clairement pas construits à l'échelle. J'ai récemment rencontré ce problème avec 2 Go de RAM
user1133275
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.