Что: fce114a42d69ac04eb4ece1e5ed5b6f5e9515068
Когда: 2023-12-10 11:01:38+03:00
Темы: 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 и забывая что он не про надёжность записи, а только про доступность данных в случае выхода из строя диска.
Сгенерирован: SGBlog 0.34.0