Сегодня, после распаковки очень большого архива, один из наших серверов Red Hat перестал отвечать. После перезагрузки мы получили следующую ошибку файловой системы.
Inode 93464 слишком велик. Непредвиденное несоответствие. Запустите fsck вручную.
Запуск fsck немедленно побуждает нас усечь индексный дескриптор.
Это вызвало ряд вопросов. Мол, как и Inode стали большими? Что произойдет, если вы усечите указанный индексный дескриптор. Я предполагаю, что вы теряете логический доступ к файлу и / или каталогу, на который ссылается индексный дескриптор вместе с любой другой ссылкой на другие связанные индексы. Мы используем Redhat Enterprise 4.
Проверьте вашу версию e2fsprogs (например, e2fsck -V). По-видимому, была ошибка до версия 1.40.2 это может привести к тому, что e2fsck (который вызывается fsck для файловых систем EXT2 / EXT3) неправильно сообщит о повреждении файловой системы этого типа:
Исправьте ошибку в e2fsck, из-за которой он неправильно спасал каталоги, когда rec_len последней записи слишком велик. Это привело к бессмысленному сообщению о повреждении файловой системы и потребовало второго запуска e2fsck для полного исправления каталога.
На серверах RHEL 4, к которым у меня есть доступ, установлена версия 1.35, так что это может быть настоящей причиной вашей проблемы. Возможно, для уверенности стоит установить более новую версию и снова запустить fsck.
Если это не помогает, возможно, проблема в файловой системе. В соответствии с эта тема, похоже, это может произойти, если у вас есть каталог, содержащий очень большое количество файлов (миллионы или больше). «Исправление» с помощью fsck приведет к усечению inode, как вы видели. В случае индексного дескриптора каталога усечение приведет к тому, что каталог «потеряет» файлы, и эти потерянные файлы окажутся в каталоге lost + found файловой системы. Они будут названы по их номерам inode, а не по исходным именам, поэтому, хотя у вас все еще есть файлы, их будет сложно отличить друг от друга.