Почему FSCK работает, даже если у вас никогда не было нечистого выключения?

man 8 tune2fs на самом деле отвечает на оба ваших вопроса:

-c max-mount-countts

Отрегулируйте количество монтирований, после чего файловая система будет проверена e2fsck (8). Если max-mount-countts равен 0 или -1, то количество раз монтирования файловой системы будет игнорироваться e2fsck (8) и ядром.

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

Вы должны строго рассмотреть последствия полного отключения проверки, зависящей от количества монтирования. Неисправные диски, кабели, память и ошибки ядра могут повредить файловую систему, не помечая файловую систему как грязную или по ошибке. Если вы используете журналирование в своей файловой системе, ваша файловая система никогда не будет помечена как грязная, поэтому она обычно не проверяется. Обнаруженная ядром ошибка файловой системы по-прежнему вызывает fsck при следующей перезагрузке, но может быть уже слишком поздно, чтобы предотвратить потерю данных на этом этапе.

Смотрите также параметр -i для проверки, зависящей от времени.

‮

-i интервал между проверками [d | m | w]

Настройте максимальное время между двумя проверками файловой системы. Никакой суффикс или d не будет интерпретировать числовой интервал между проверками как дни, m как месяцы, а w как недели. Нулевое значение отключит зависящую от времени проверку.

Настоятельно рекомендуется включить либо проверку -c (mount-count-based), либо -i (зависящую от времени), чтобы вызвать периодическую полную проверку e2fsck (8) файловой системы. Невыполнение этого требования может привести к тому, что повреждение файловой системы (из-за неисправных дисков, кабелей, памяти или ошибок ядра) останется незамеченным, что в конечном итоге приведет к потере или повреждению данных.

Что касается определения частоты проверок (после max-mount-counts или пороговых значений интервала между проверками ), установленных в вашей собственной файловой системе ext2 / ext3 / ext4, вы можете запустить эту команду:

sudo dumpe2fs /dev/YOURDEV | grep -Ei '(mount count|interval|check)' 

Замените /dev/YOURDEVна раздел, который вы хотите изучить.

Образец вывода:

deltik@node51 [~]$ sudo dumpe2fs /dev/nvme0n1p3 | grep -Ei '(mount count|interval|check)' dumpe2fs 1.42.13 (17-May-2015) Mount count: 1 Maximum mount count: -1 Last checked: Tue Mar 15 13:30:00 2018 Check interval: 0 (<none>) 

Действительно ли FSCK нужен, даже если у вас никогда не было нечистых отключений?

Это зависит от. Можете ли вы гарантировать со 100% уверенностью, что вы никогда не будете иметь какие - либо повреждения данных в системе хранения под файловую систему?

Как правило, проверка файловой системы функционально обязательна после нечистого завершения работы некоторых файловых систем (особенно старых, особенно ext4), но нечистое завершение - не единственная ситуация, которая может привести к повреждению внутренних структур данных файловых систем. Некатастрофические сбои устройства (плохие сектора, плохое встроенное ПО и т. Д.) Могут вызывать одно и то же повреждение, поэтому рекомендуется проверять время от времени, даже если ваша система не дает сбоя и не теряет питание.

Это особенно важно для ext4, потому что:

• При использовании журналирования (если вы не знаете, ведете ли вы журналирование или нет, возможно, так оно и есть), файловая система может никогда не быть проверена иначе, потому что журнализированная файловая система считается самосогласованной даже после нечистого завершения работы.
• Поведение по умолчанию при обнаружении ошибок в метаданных файловой системы во время выполнения - просто зарегистрировать проблему и продолжить, как будто ничего не произошло. Это означает, что по сравнению с другими файловыми системами (например, XFS, BTRFS или ZFS) гораздо менее вероятно, что вы заметите, если есть проблема с файловой системой, пока не станет слишком поздно ее исправить.