[О блоге] [наверх] [пред] [2023-12-10 11:01:38+03:00] [fce114a42d69ac04eb4ece1e5ed5b6f5e9515068]
Темы: [hate][systemd][zfs]

Баги в файловых системах

https://www.opennet.ru/opennews/art.shtml?num=60261
https://www.debian.org/News/2023/2023120902
https://www.opennet.ru/opennews/art.shtml?num=60167
Тут вот много всяких "линуксоидов" смеялось на тему того, что в
стабильной production über ready ZFS файловой системе появилась
проблема которая может молча привести к потере данных. И при этом
все умудряются повторять как мантру что их простая ext4 является
самой надёжностью. А тут вот Debian откладывает свой релиз из-за
того, что в ext4 порча данных возможна.

Вот только я не раз помню что в ext4 проблемы с потерями данных
уже бывали. И в том же ivi, где активность/нагрузка на ФС кэширующих
серверов была не маленькая -- там реально приходилось просто с нуля
создавать ФС (ext4), ибо она приходила в непонятное полурабочее
неконсистентное состояние. Об этом линуксоиды дружно забывают и
закрывают глаза.

ReiserFS -- первая журналируемая ФС для Linux. Аналогично, даже не
смотря на журнал, всё равно могла стать неконсистентной. Я поэтому уже
давно и говорю, что в мире Linux, среди изобретённых для него ФС -- не
было ни одной железобетонно стабильной и надёжной. ZFS-on-Linux -- тоже
имел проблемы с data corruption как-то. OpenZFS вот имел багу, но...
сколько людей реально на неё напоролось и пострадало? Про "стабильность"
Btrfs уже ходят легенды.

А ещё находятся люди, кто говорит что "вот на ext2" или
"подставить-любую-не-журналируемую" проблем не было (ну или ФС без soft
updates, но это мир BSD). Ага, только после перезапуска внезапного можно
привести в неконсистентное состояние, по сути просто даже потерять всю
ФС. Кто-то говорит про software RAID -- ага, закрывая глаза на write
hole и забывая что он не про надёжность записи, а только про доступность
данных в случае выхода из строя диска.

    [оставить комментарий]