> И как оно? write hole пропал?У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.
> А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а)
> тоже переживает?
Это не имитация битфлипа, т.к. от оригинальных данных вообще ничего не останется, даже суперблоков, и нельзя ЭТО идентифицировать как девайс пула. Буквы дисков это прекрасно но их порядок при загрузке не гарантирован. В случае полного отказа девайса, если НИЧЕГО вообще нет, логичнее замену девайса делать, с ребилдом порушеного на новый. Но если это все постепенно - будет орать про чексумы и фиксить их, куда оно денется?
Из _реалистичных_ проблемных сторажей точно переживает работу на текучках и сыпучках с DUP (так можно юзануть фиговую флеху/карту, одну). Просто берет и чинит - и теорвер так намного прикольнее. Теперь проигрыш не при 1 бэде в чем-то критичном, а при совпадении когда бэды сразу в 2 копиях - в физически разных местах - что довольно маловероятно. Вот так теорвер гораздо прикольнее ощущается. "Еж пищит, орет, но живет".
> OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не
> переживало. Но то было несколько лет назад.
Они все же несколько разные по структуре. И если на девайсе вообще ничего не осталось - он не опознается как свой за отсуствием суперблоков. Но если на стораже не осталось нифига вообще, это replace девайса уже, а не фоновый фикс нифига. Т.к. полный отказ.
А с реалистичной точки зрения что-то сравнимое я видел только при слете транслятора на дешевом хламе типа карт и флех - и в этом случае всяко потребуется мануальщина для замена развалившегося вдрызг девайса. Пытаться такое чинить не стоит: склонно разлетаться вновь, даже если кажется что вроде починилось, реально та еще мина получается.
> Во-1, я о том и сказал, что no-CoW файлы с образом диска
> виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят.
Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.
> Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть
> (ну или почти), и наоборот, летают быстрее голого диска. Это всё
> на свежесозданных пустых ФС.
Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс. Это какое-то извращение понятное только ZFSникам. Я конечно понимаю что гребля только с девайсами и размерами слишком скучно, надо еще и вон той гребли добавить. А btrfs так то о простом и ненапряжном менеджменте. В гробу я видел управление какими там vol'ами дополнительно к остальному еще. В btrfs управление сводится по сути к add/remove/replace девайсов да может смене схемы. Удобно. А если стало мало места, можно подоткнуть +1 девайс. Ну может ребаланс пнуть если использование устройств сильно асимметричное вышло. Прокатит даже с RAID1 или там RAID5 каким. Без академической гребли с выравниваниями, рестрайпами, размерами и проч. За одно это авторам дизайна памятник надо поставить имхо.
> Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет
> паковаться (и фрагментироваться).
Насчет блоков: видите ли, это вовсе и не фича. Потому что, внезапно, не extent based дизайн даже еще! А какой-то block-based переросток. В чем трабл? Без ломового подпора рамой такой дизайн тормозной аки трактор! А btrfs почти как ext4, даже на роутере с 64 метрами оперативы (попробуйте там ZFS завести?!). Из-за этого как я понимаю на него рефлинки натянуть не смогли. Можно конечно поспорить за экстентные аллокаторы и их эффективность, но т.к. в целом мир выбрал для новых дизайнов их, они таки эффективнее в большинстве кейсов оказались. А btrfs живет даже на очень мелких конфигах, типа одноплатников и довольно непозорно я б сказал. Имея свои плюсы. Например, не дохнет от 1 бэда насмерть как EXT4. Да, представляете, 1 бэд под libc6 в EXT4 = система не грузится. То же самое на btrfs с dup - "csum failed ... corrected". Такая вот разница.
> Например, 1 мегабайт. Меньше не будет.
Ага, могу себе представить латенси всего этого и оверхед в менее удачных случаях, когда надо было 4К блок, а оно весь мег в результате кантовало.
> А в btrfs оно само будет резать на кусочки килобайт 128 упакованного -
> 16 неупакованного. А если в середину экстента с 128к данных байт
> записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.
Я это специально не проверял, но в среднем файлухи с сжатием и проч ведут себя вполне одупляемо в целом вроде. Наверное можно подобрать дурацкие случаи, но их для чего угодно подобрать можно.
> Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый
> тоже имеется.
Ну если дефраг это "техническое зло" то вот простое, гибкое и удобное управление + снапшоты это одна из вещей за которые есть смысл потерпеть необычные причуды инопланетного дизайна. Потому что менеджмент систем переходит на совсем иной уровень.
> Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2
> дисках (и 2 sparse файлах на рамдиске, после чего те файлы
> отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками
> с loop deviceами.
Так их почти вроде все на loop девайсах и собирают. Ну и это как-то не основной кейс чтобы меня сильно парить.
> А ещё, в OpenZFS шифрование по-датасетно искаропки.
А это разве не в оракле только? Или они таки доделали?
> В btrfs вроде ещё не довпилили, хотя грозятся.
Ну да. И это еще можно записать в минусы - т.к. хоть и решаемо иными методами, но в ущерб вон тому, удобному менеджменту. Что как бы несколько пролюбливает пойнт.
К сожалению продвинутость дизайна имеет и обратные стороны медали... https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@re.../
