JFS: долгое время fsck на большой файловой системе?
Недавно произошел сбой питания, который отключил один из моих серверов. При перезагрузке основной файловой системе хранения - JFS в файловой системе 7 ТБ (9x1 ТБ RAID6) - требовался fsck перед монтированием операций чтения-записи. После того, как я запустил fsck, я некоторое время наблюдал за ним в топе - использование памяти неуклонно росло (но не слишком быстро), а загрузка ЦП поддерживалась на уровне или около 100%.
Теперь, примерно через 12 часов, процесс fsck потребил почти 94% 4 ГБ памяти в системе, а загрузка ЦП снизилась примерно до 2%. Процесс все еще выполняется (и не указывает на дальнейшее время выполнения).
Прежде всего: это свидетельствует о проблеме? Меня беспокоит тот факт, что загрузка ЦП так резко сократилась - кажется, что процесс стал ограниченным объемом памяти, и fsck потребуется вечно, чтобы завершиться, поскольку он тратит все свое время на подкачку. (Я заметил, что kswapd0 перемещается неудобно близко к вершине списка вверху, фактически выбивая процесс fsck из-за использования ЦП более половины времени.) Если это не так, если fsck просто замедляет работу ЦП в конце процесса, это нормально - мне просто нужно это знать.
Если это проблема, что я могу сделать, чтобы улучшить производительность fsck? Я открыт практически для всего, вплоть до "купи больше памяти для системы".
Соответствующая строка сверху:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5201 root 20 0 58.1g 3.6g 128 D 2 93.8 1071:27 fsck.jfs
И результат бесплатный -m:
total used free shared buffers cached
Mem: 3959 3932 26 0 0 6
-/+ buffers/cache: 3925 33
Swap: 964 482 4822 ответа
Основываясь на использовании виртуальной памяти, я решил, что невозможно выполнить полный fsck на томе в любое разумное время (даже с дополнительной оперативной памятью), поэтому я сделал резервную копию всех файлов на томе и переформатировал с помощью XFS.
Поправьте меня, если я ошибаюсь, но JFS не является полной файловой системой журналирования: она обрабатывает только метаданные в журнале. Это означает, что выполнение команды fsck займет много времени, если у вас много данных.
Я предлагаю вам изучить возможность перехода на полностью журнализированную файловую систему (etx3/4): это должно устранить необходимость запуска команды в случае внезапного сбоя.