Комментарии 6
Ура, наконец-то. Любопытно всё же, в чём была такая сложность этой фичи, потребовавшая годы на реализацию. Аппаратные RAID-контроллеры, железо которых несопоставимо слабее, чем у серверов, уверенно тянущих ZFS, умеют расширять RAID 5/6 с незапамятных времён.
RAIDZ, по функциональности во многом схожий с RAID 5 и RAID 6, но обладающий одним существенным отличием — все диски внутри группы RAIDZ одинаковы. То есть у всех дисков в группе RAIDZ одинаковый удельный вес и отсутствуют диски с особой ролью (parity, data parity).
Ну вообще-то у RAID 5/6 тоже отсутствуют диски с особой ролью, parity блоки равномерно распределены по всем дискам. С особой ролью - это RAID 3 и 4, которые в живой природе встречаются примерно никогда.
Любопытно всё же, в чём была такая сложность этой фичи, потребовавшая годы на реализацию. Аппаратные RAID-контроллеры, железо которых несопоставимо слабее, чем у серверов, уверенно тянущих ZFS, умеют расширять RAID 5/6 с незапамятных времён.
Аппаратный контроллер наружу представляется всего лишь блочным устройством. OpenZFS -- это файловая система, которая программно реализует raid, а также контроль целостности и атомарные записи (ну и ещё кучу всего). А ещё там куча legacy кода от легендарного Sun, и не факт что тот код оптимальный или легко модифицируемый (я лишь предполагаю, в глаза тот код не видел и не разбирался). Обеспечивать перестройку RAID надо, не нарушая основной сервис (работу с файлами) и не нарушая существующие гарантии атомарности/крешеустойчивости/etc. Вот и сравните теперь с аппаратными raid-железками, которые к тому же ещё и на батарейку полагаются для гарантий синхронных записей и крешеустойчивости. OpenZFS все эти проблемы решает чисто программно.
Любопытно всё же, в чём была такая сложность этой фичи
да как бы в статье вроде бы прямо говорится что дело не в сложности а в том что требует очень долгой и сильно грузящей процессор операции перераспределения:
Это обусловлено тем, что модификация размера группы RAIDZ требовала очень длительной операции по перераспределению существующих данных
ведь по большому счёту даже учитывая непростую математику используемую для работы raidz по большому счёту передвинуть блоки с диска на диск, а потом посчитать блоки чётности и положить рядышком относительно не сложно, но очень затратно по времени. в btrfs два диска на 14тер из mirror в stripe превращались емнип у меня дня 4 с балансировкой, а у некоторых в ведении хранилища объёмы которых измеряются десятками петабайт, так ещё и обслуживание лучше проводить без даунтайма..
Аппаратные RAID-контроллеры, железо которых несопоставимо слабее, чем у серверов, уверенно тянущих ZFS, умеют расширять RAID 5/6 с незапамятных времён
прикол в том что "мозг" аппаратного рейд контроллера только этим и занимается, и тяжёлая операция перераспределения блоков не грузит CPU вашего сервера тем самым напрямую не влияет на его общую производительность, когда же у вас zfs/btrfs перераспределение займёт процессор сильно, и остальным сервисам будет нехватать
а вообще ИМХО хорошо что сделали, в btrfs это возможно давно, более того можно в любой момент превратить raidc3 (аналог raidz) в raid10 и обратно не говоря уж об добавлении или уменьшении кол-ва дисков (с уменьшением кол-ва дисков в zfs кстати тоже всё не очень хорошо), а решение стоит ли грузить этой операцией процессор или нет предоставлено инженеру.
интересно пощупать что там в этом плане у bcachefs конечно..
Я так понимаю там проблемма не столько в проц упирается, посчитать что куда, сколько в iops, я даже боюсь представить сколько и как надо перелопатить данные что бы скажем к 7 дискам добавить еще 1
зы. а только Z1 можно или 2й и3й тоже....
Что самое обидное - это отсутствие изменения ширины группы для существующих данных и приличного размера overhead у старых данных, который имеет накопительный эффект :(
vStack стал спонсором и контрибьютором новой значимой функциональности ZFS: RAIDZ Expansion