Должен ли я беспокоиться о неправильном количестве свободных блоков/inode/сирот в ext4?

Вопрос или проблема

$ sudo fsck -vn /dev/lvmroot/root 
fsck из util-linux 2.40.2
e2fsck 1.47.1 (20-май-2024)
Внимание!  /dev/mapper/lvm/root смонтирован.
Внимание: пропуск восстановления журнала, так как выполняется проверка файловой системы в режиме только для чтения.
root был смонтирован 1 раз без проверки, проверка принудительная.
Проход 1: Проверка инодов, блоков и размеров
Проход 2: Проверка структуры каталогов
Проход 3: Проверка связности каталогов
Проход 4: Проверка ссылок
Проход 5: Проверка сводной информации по группам
Количество свободных блоков неверно (12783960, подсчитано=12783944).
Исправить? нет

Количество свободных инодов неверно (5263640, подсчитано=5263625).
Исправить? нет

Функция orphan_present установлена, но файл-осиротел остался в чистом виде.
Очистить? нет
      503528 инодов использовано (8.73%, от 5767168)
         271 неконтинуальных файла (0.1%)
         237 неконтинуальных каталогов (0.0%)
             # инодов с блоками ind/dind/tind: 0/0/0
             Гистограмма глубины экстента: 448994/96
    10284712 блоков использовано (44.58%, от 23068672)
           0 плохих блоков
           5 больших файлов

      409720 обычных файлов
       37767 каталогов
           0 файлов символических устройств
           0 файлов блочных устройств
           0 fifo
        4248 ссылок
       56022 символических ссылок (54421 быстрая символическая ссылка)
          24 сокета
------------
      507781 файлов

Ответ или решение

Вопрос о том, следует ли беспокоиться о неправильных счетчиках свободных блоков/инодов/сирот в файловой системе ext4, имеет несколько аспектов.

1. Понимание проблемы: Ваша команда fsck сообщает о несоответствии между ожидаемым и фактическим количеством свободных блоков и инодов, а также о наличии установленного параметра orphan_present, при этом никаких орфанных файлов не найдено. Это может сигнализировать о потенциальных ошибках в метаданных файловой системы, что в свою очередь может повлиять на стабильность и производительность вашего хранилища данных.

2. Риски: Если проблема остается нерешенной, это может привести к более серьезным проблемам в будущем, таким как потеря данных или повреждение файловой системы. Особенно это актуально для систем, на которых часто выполняются операции записи и удаления файлов. Учитывая, что файловая система уже была замонтирована и проверка была пропущена, это может указывать на то, что в предыдущий раз система была неправильно завершена.

3. Настройка fsck: Хорошей практикой является планирование регулярной проверки файловой системы, даже несмотря на вашу настройку на выполнение fsck при каждом перезагрузке. Возможно, стоит проверить, правильно ли настроены параметры, относящиеся к вашим файловым системам в /etc/fstab, чтобы fsck выполнялся корректно.

4. Рекомендации по исправлению: Рекомендуется запланировать время для исправления данных ошибок. Вы можете сделать это, перезагрузившись в режим однопользовательской работы или загрузившись с live CD/USB, а затем запустив fsck с параметрами исправления на вашем корневом разделе. Это обеспечит, что файловая система будет не смонтирована во время выполнения проверки и исправления. Выполните команду:

   sudo fsck -f /dev/mapper/lvm/root

   Параметр -f принудительно запустит проверку, даже если система полагает, что на ней нет ошибок.

5. Частота проверок: Необходимо понимать, что даже если вы предусмотрели автоматическую проверку при загрузке, могут возникнуть ситуации, когда это не сработает, как в вашем случае. Убедитесь, что вы периодически проверяете состояние вашей файловой системы вручную и создаете резервные копии важных данных.

6. Профилактика: После успешного исправления ошибок рекомендуется следить за показателями состояния файловой системы с использованием различных инструментов мониторинга или периодически запускать fsck для предотвращения подобных ситуаций в будущем.

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