Исходное сообщение
"Код Bcachefs принят в основной состав ядра Linux 6.7" Отправлено Аноним, 08-Ноя-23 23:12
> Ext4 ... полный журнал тормозной как черти что > придумали NOCOW От новых файловых систем всякого хотят. Кому-то без data journal норм, а с потерей новых фич в nodatacow - не норм. Ладно сжатие отваливается, но ведь и data checksumming тоже. Осталось добавить в btrfs шифрование и тоже его отрубить для nodatacow. > Заниматься всякой многоэтажной камасутрой с супер-решениями хз зачем, черти-чьими технологиями > хз где и трехэтажными наслоениями костылей - не мое, мне удобно Шифрования в btrfs нет. Придётся наслаивать. RAID5/6 в btrfs "как бы нет". Снова наслаивать. Cryptsetup предлагает добавить контрольные суммы для всего (добавить dm-integrity уровнем ниже dm-crypt). Тут уже задумаешься, нужно ли сверху наслаивать именно btrfs, а не что попроще, если одна из её фич так легко замещается*, а красиво, шоб всё в одном как в ZFS, всё равно не получается. И глядя на ZFS начинаешь сильнее ценить гибкость, потому что слишком многое там делается через "Если к вам пришли гости, а у вас ничего нет, пошлите человека в погреб, пусть принесёт фунт масла, два фунта ветчины, дюжину яиц, фунт икры, красной или чёрной, и приготовьте лёгкие закуски"... то есть "пошлите человека в погреб, пусть принесёт стопку HDD, чтобы собрать ещё один массив и таким образом отменить дедупликацию, сделать дефрагментацию или ещё какую мелочь". Уж что-что, а невероятную гибкость MergerFS+SnapRAID даёт**. Ещё журнал ext4 и контрольные суммы dm-integrity выносятся на отдельное устройство побыстрее. Вроде костыли, но зато какие - можно пальцем показывать на SPECIAL vdev в ZFS. Чем менее популярна ФС, тем меньше инструментов для восстановления данных, тоже такое. * но будет сложнее искать, какой файл задел битый сектор ** это звучало бы убедительнее, если бы я сам ими пользовался