> Да несколько лет назад в течение довольно длительного времени в реализации ext4
> в ядре Linux была ошибка, приводящая к повреждению фс, включая повреждение
> файлов, как системных, так и в home. В качестве вокрараунда я
> ставил полную проверку ФС на каждый перезапуск через добавление файла в
> корень через systemd unit и перезагружался почаще (каждая перезагрузка занимала долгое
> время). Если не перезагружаться почаще - можно было возможно вылететь, и
> после - загрузиться в initrd и полсистемы через пакетный менеджер переустанавливать.
> Я ещё подозревал аппаратные проблемы с жёстким диском, но диск был
> хитачи и имел хорошие SMARTы. Хорошо что купить новый диск я
> не мог, это были бы потраченные на ветер деньги....а чтобы не заниматься всей вот этой НЕВМЕНЯЕМОЙ ХРЕНЬЮ вместо эксплуатации систем я и юзаю btrfs ;).
Там если железо сбоит - вопли "csum error" сразу покажут что хардвар дурит. Даже если винч исправный, это не доказывает что проц, чипсет и память ведут себя как надо. И какая разница кто из них битик вон там крутанет или неправильно посчитает. В результате можно получить факап и очень плохо если это - ВНЕЗАПНО. Гадать корректно ли работает железо это булшит, end to end проверки с чексумами - EPIC WIN, и по этой фиче я полностью согласен с ZFS'никами.
А делать перезагрузки и fsck - извините, но это прерывает доступность сервиса а на современных размерах томов fsck еще и совсем не быстрая операция. Это компы для людей - или мы еще будем тут изгибаться в три погибели под какие-то дурацкие техниеские особенности? А оно в таком виде - точно надо?
Про то что онлайн проверка и вообще-то scrub, а желательно с self heal из избыточной копии, если она есть - это хорошо и правильно - даже и упоминать неудобно. Автралопитеки с EXT4 с бамбуковым самолетом вообще не понимают прелестей бортового компьютера (из бамбука он фигово эмулируется, увы).
В этом аспекте я таки понимаю ZFSников. А subj - ну, они что-то нагнули в процессе разработке и таки какие-то проблемы с "общим качеством кода" кажется пошли.
