fsck работает более 30 дней на 30 ТБ разделах ext4, не может быть подключен

332
G Grosschmid

Учитывая раздел 30ТБ дисков на hw raid5. LVM находится сверху, а файловая система - ext4. (Он заполнен данными на 99,9%.) Я хотел добавить еще 20 ТБ и изменить размер раздела и файловой системы. Перед изменением размера он настаивал на запуске FSCK. Он работал более недели, я отменил, но не смог смонтировать раздел. FSCK был необходим в первую очередь. Итак, я начал это снова.

fsck.ext4 -v -C 0 /dev/vgname/lvname e2fsck 1.44.3 (10-July-2018) Superblock has an invalid journal (inode 8). Clear<y>? yes *** journal has been deleted ***  Resize inode not valid. Recreate<y>? yes

И с тех пор, как прошло 31 день, он все еще работает, занимая 1 ядро ​​процессора на 100%.

Когда я смотрю на это со стразами, вот что я вижу:

strace -p 3174 strace: Process 3174 attached strace: [ Process PID=3174 runs in x32 mode. ] strace: [ Process PID=3174 runs in 64 bit mode. ] pread64(4, "\375\210\372\374\360\10\375=$\375\254\221\375\334\361\375l?\376?U\376\24?\376\27\351\375:\305\375\217"..., 4096, 2447145635840) = 4096 mremap(0x7fa5e3565000, 208764928, 208769024, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "\0\305\7\0\321\376\377q\367\377Q\364\377\371\361\377H\355\377\323\346\377\271\337\377\275\332\377J\326\377\16"..., 4096, 1724118507520) = 4096 pread64(4, "x\377\371p\377_b\377\177W\377\35[\377\223N\377\226[\377&h\377QS\377\203O\377sT\377"..., 4096, 3443764559872) = 4096 pread64(4, "\377\263\371\377\375\355\377\363\6\0\367\356\377\326\21\0\350\353\377?\30\0\242\345\377\375\26\0|\344\377D"..., 4096, 6956990242816) = 4096 pread64(4, "\0\3201\273\0\24)\273\0\34=\273\0\336/\273\0\316/\273\0\3167\273\0\220*\273\0\3569\273"..., 4096, 8609803698176) = 4096 pread64(4, "o\f\257\205\16\377=\20\367\270\21\376\312\22\252R\0234\227\23\242\303\23\234\343\23Z\376\23LI\24"..., 4096, 1755810463744) = 4096 mremap(0x7fa5e3565000, 208769024, 208773120, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "\22\0\\\2\0\347\352\377\347\303\377?\250\3776\224\377Ht\377\17W\377\245G\377\5G\377}[\377"..., 4096, 14672424988672) = 4096 mremap(0x7fa5e3565000, 208773120, 208777216, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "\255\2\202)#m\22\5N\244F\210\221\20+.\21\5\352\306\344\220\25\3567\250\16\323\2\247P\352"..., 4096, 16981972766720) = 4096 mremap(0x7fa5e3565000, 208777216, 208781312, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "M\0\205N\0KO\0\4P\0\221P\0)Q\0\336Q\0\204R\0SS\0\tT\0\371T\0"..., 4096, 833004105728) = 4096

Новая линия выпускается каждые 30-60 секунд, так что довольно редко. Может ли кто-нибудь дать мне понять, что происходит, и буду ли я ждать или что нужно сделать, чтобы снова получить доступ к данным?

6
Я вижу, что вы запустили `fsck.ext4` с аргументом` -C 0`, который должен создать индикатор выполнения. Как далеко продвинулась планка к тому времени, когда вы заметили, что это заняло много времени? После этого планка продолжала расти? kasperd 5 лет назад 0
Спасибо, несмотря на флаг, никакого прогресса не было, поэтому я был ошеломлен. G Grosschmid 5 лет назад 0
Похоже, ошибка в `fsck.ext4`. kasperd 5 лет назад 0

2 ответа на вопрос

0
antony_sebastian

Пожалуйста, выполните следующие шаги,

Сначала размонтируйте диск,

umount / dev / disk

Linux поддерживает несколько избыточных копий суперблока в каждой файловой системе. Мы можем восстановить данные, используя избыточные копии метаданных суперблока.

dumpe2fs / dev / disk | grep суперблок

Он покажет альтернативные суперблоки, которые мы можем использовать.

fsck -y -b blockid / dev / disk

Повторите шаг для всех поврежденных суперблоков. т.е. заменить суперблоки резервным суперблоком.

смонтировать диск и использовать снова

Это ваш собственный сайт? Обратите внимание, что вы должны четко указать это, см. [Справочный центр] (/ help / продвижение). Glorfindel 5 лет назад 1
Спасибо за предложение! Я решил попробовать, вошел на сервер и возобновил работу с screen -r, мне предложили несколько десятков вопросов, на которые я ответил да, и все закончилось. РЕЗУЛЬТАТ: все ~ 1250 папок потеряли свои имена и были перемещены в «lost + found». Нужно переименовать каталоги снова, но контент в противном случае, похоже, выжил. G Grosschmid 5 лет назад 0
@GGrosschmid, если это ответило на ваш вопрос, пожалуйста, нажмите на значок галочки рядом с ответом, чтобы указать, что он правильный, решающий вашу проблему. music2myear 5 лет назад 0
0
G Grosschmid

Спасибо всем за предложения. Диск был размонтирован уже до того, как я запустил fsck. После того, как я получил ответное предложение от antony_sebastian, я вошел на сервер, чтобы попробовать это, возобновил свою экранную команду и fsck ждал ввода. Удивительно, но после 33 дней проверки он завершил обработку диска объемом 30 ТБ. Отвечая «да» на все устраняемые проблемы, данные вернулись, хотя все переместилось в «Lost + found» и имена папок корневого дерева каталогов были потеряны. Кроме этого данные были нетронуты и в порядке.

Спасибо за предложения и помощь всем!

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