Случайно измененный ext4fs предел на более чем 16 ТБ, как откатывать?

Мы пытались увеличить размер нашего раздела на 15 ТБ с lvresize со следующей командой:

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

Никакие ошибки не были отображены во время операции, но результатом была своего рода катастрофа. Никакие файлы больше не были видимы, и целый диск, казалось, был пуст.

syslog содержавший следующие ошибки:

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

Нам удалось umount раздел и план состояли в том, чтобы работать fsck зафиксировать его:

$ 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 *****

Хорошо, затем затем пытаясь перечислить доступные альтернативные суперблоки:

$ 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.

Таким образом, похоже, что нам удалось случайно пробежаться через предел на 16 ТБ с lvresize и нашему ext4fs не включили 64-разрядное значение параметра.

После этого мы пытались уменьшить размер назад к ниже предела на 16 ТБ, но resize2fs не работает также, потому что он думает, что раздел (очевидно) грязен и не хочет делать что-либо с ним.

Какие-либо рекомендации, который направление взять затем? Выполненный изменяют размер с силой или пытающийся включить 64-разрядное значение параметра? Что-то еще?

dumpe2fs дисплеи это (среди другой информации):

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

Информация о соответствующей версии:

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

ОБНОВЛЕНИЕ: После прочтения некоторого исходного кода мы нашли первопричину для проблемы: https://github.com/torvalds/linux/commit/4f2f76f751433908364ccff82f437a57d0e6e9b7

Вопрос все еще остается, как восстановиться с ситуации, где количество inode было сброшено к 0 благодаря водосливной ошибке.

2
задан 10 October 2018 в 14:39

1 ответ

Кажется, что странное поведение относительно использования lvresize - resizefs опция вместе с файловой системой расширения и to-the-last-byte завершается раздел, 16 ТБ шириной был увиден в первый раз уже назад в 2009: (https://www.redhat.com/archives/ext3-users/2009-January/msg00003.html)

"Мы должны, вероятно, заставить mkfs просто тихо сократить один блок, если он встречается с граничным условием как это..."

Кредиты конца?

Мы смогли зафиксировать ситуацию путем взламывания суперблока вручную. Мы взяли снимок LVM ситуации с запуском сначала. Затем мы вывели первые 64k байты раздела в файл для более близкого исследования. Количество Inode и значения количества Блока в самом начале Суперблока были повреждены из-за упомянутой выше ошибки. (https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout)

Согласно изучению e2fsprogs исходный код мы решили, что путем записи количества Inode и значения количества Block одна Block Group, меньшая (32k) максимума к Суперблоку, могла быть хорошей вещью попытаться, это работало. Байты были

00 80 ff ff 00 80 ff ff

и мы просто dd'ed их к разделу.

С новейшей версией самоскомпилированного e2fsprogs' fsck смог зафиксировать остальную часть ошибок. Все кажется хорошо теперь.

1
ответ дан 2 December 2019 в 04:41

Другие вопросы по тегам:

Похожие вопросы: