Безопасна ли файловая система ext4?

My main concern is that such damage NEVER happened to disks partitioned to NTFS, whatsoever.

Этого, может быть, никогда не случалось с вами , но это случилось. Единственные файловые системы, которые могут утверждать, что подобные вещи никогда не происходят, — это те, которые никогда не подвергались воздействию таких условий. Даже BTRFS и ZFS, которые разработаны, чтобы быть устойчивыми к подобным вещам, могут иметь такие проблемы.

На ваши насущные вопросы:

Is ext4 safe in general? I mean is it me or are there other people who experienced loss of disks/information on disks formatted to etx4?

Это зависит от того, что вы подразумеваете под «безопасным». Я лично терял данные на дисках, отформатированных с помощью ext4, но каждый раз, когда это случалось со мной, это происходило из-за плохого оборудования, и, что более важно, в конечном итоге это произошло бы практически с любой другой файловой системой. Несмотря на это, я все еще регулярно использую его для многих целей, потому что, за исключением ошибок пользователя или проблем с оборудованием (, включая неожиданное отключение питания ), он просто работает. Итак, я считаю его "безопасным" по определению большинства людей, но вы можете или не можете.

In Linux world, what could be a safer alternative to ext4 that can outlive unexpected electricity switch off or unexpected unmounting?

Нет, если только вы не хотите устранить другие ограничения или проблемы. В частности:

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

Однако вы можете сделать несколько вещей, чтобы сделать ext4 более безопасным:

• Изменение поведения при обнаружении ошибок. По умолчанию, если в метаданных файловой системы встречается ошибка, ext4 просто помечает том как требующий проверки, а затем ведет себя так, как будто ничего не произошло. Это делает только файловая система в Linux, все остальное будет перемонтировать том только для чтения -, таким образом предотвращая ухудшение ситуации при любых операциях записи в файловую систему. Вы можете получить такое поведение на ext4, добавив errors=remount-roв параметры монтирования или запустив tune2fs -e remount-roна блочном устройстве, содержащем файловую систему.
• Убедитесь, что вы не используете режим обратной записи для журнала. Вы можете убедиться в этом, дважды проверив параметры монтирования тома и убедившись, что journal=writebackотсутствует в списке. Режим обратной записи журнала может значительно повысить производительность определенных рабочих нагрузок в файловых системах ext4, но повышает вероятность потери данных при неожиданном отключении питания.
• Если вы хотите быть действительно параноиком в отношении безопасности данных, вы можете включить режим журналирования данных. Обычно журнал в файловой системе ext4 отслеживает только изменения метаданных (, переименования, удаление или создание файлов, обновления меток времени и т. д. ). В режиме журналируемых данных все изменения проходят через журнал. Это значительно замедляет работу, но обеспечивает 100% функциональную гарантию того, что файловая система останется внутренне непротиворечивой. Вы можете включить это, передав journal=dataв параметрах монтирования.
• Вы можете добавить опцию монтирования auto_da_alloc. По сути, это обнаруживает приложения, которые не вызывают fsync(), когда они должны, и правильно обрабатывает ситуацию. Это не значение по умолчанию, потому что это немного замедляет работу, и большинству приложений это не нужно.
• В новых ядрах можно включить контрольную сумму журнала. На самом деле это не «сохранит» ваши данные, но поможет гарантировать, что вы не получите поддельные данные обратно, когда произошла ошибка. Это можно включить, добавив journal_checksumв параметры монтирования.
• Если у вас достаточно новое ядро ​​и новая версия e2fsprogs, вы можете включить контрольную сумму метаданных. Подобно контрольной сумме журнала, это не сохранит ваши данные, но поможет предотвратить появление ложных данных в случае ошибки. Это должно быть включено во время создания файловой системы путем передачи -O metadata_checksum,metadata_checksum_seedв mkfs.ext4. Если вы сделаете это, вам (, вероятно, )не нужно также включать контрольную сумму журнала, поскольку журнал является частью того, что покрывается контрольной суммой метаданных.