Так я по скриптоте, а не по бутлоадерам.

Никто не знает, насколько сложно выкинуть из grub4dos 10 летней давности код, чтобы он не пытался лезти никуда кроме интегрированных USB storage и старых интегрированных SATA/IDE? Чтобы не опрашивал внешние PCI слоты расширения.

Так и знал, что шарпы- скриптовый язык

Если не было dedup

Цифры для примера приведены?

Никак

Не видел устройств такого размера..

И стоит иметь ввиду, что данные сами не ребалансятся.

Гм, всего 10 дисков по 12 тб в raidz2 - это 80 тб, по нынешним временам совсем немного

Циферки из серии «не более чем»

Точно такого не видел. Кол-во дисков в vdev определяет оверхед по объёму, всем известная табличка это показывает, в случае с raidz оверхед может быть немалым..

https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

@gmelikov Георгий, может вы подскажете про ограничение кол-ва дисков на vdev и производительность с этим связанную, а конкретно iops?

В общем с иопсами сложно будет.

ограничение верхнее технически конечно есть, 240 чтоли :) про иопсы не совсем понимаю что хочется узнать, есть базовые вещи про конкретные типы vdevs, иопсы зависят от характера нагрузки, про особенности raidz и выше комментили уже. По моим личным тестам смысла больше 30 дисков на одном raidz очень мало в плане общего решения, о чём везде, опять же, говорят. Но если нужна поточка, эффективность утилизации сырого пространства и перформансом готовы рисковать, а также потеря пула не очень страшна, то до верхнего предела в около 240 дисков на vdev далеко)

Может быть устарела. Я не использую райдзы вообще, подтвердить или опровергнуть не смогу

я вот про это и про статью из блога. мне кажется что информация как минимум устарела. не видел разницы по iops в тестах на пуле из одного vdev например из 6 дисков в raidz2 или из 11 дисков - цифры в рамках 3-5% погрешности.

это я читал, это 2015 год, а рекомендации Арена еще старше. как это соотносится с новыми версиями ZOL? вроде писали что много оптимизаций. я бы хотел увидеть рекомендации из доки по ZOL к конкретной версии

на пуле из одного raidz vdev количество дисков на random io мало влиять будет, в том и цимес

Решил снапшоты поудалять лишние, которые остались от репликации зашифрованных датасетов. Два снапшота никак не хотят удаляться, ни на приемнике, ни на источнике. Уже и перезагрузку пробовал.

в блоге человек пишет "for best performance on random iops use a small number of disks in each raidz group". про один vdev понятно, как определить зависимость кол-ва iops от кол-ва дисков в, например, 3-х vdev?

в issues что-то писали про проблемы со снапшотами и шифрованием, не ткну в конкретный увы

т.е. для raidz количество дисков не влияет на iops считай

А между вдев нагрузка параллелится же?

да, если потоков больше одного. Запись одного блока всегда приедет на один vdev, а вот запись 2 блоков параллельно может использовать уже 2 vdevs

Может это имелось ввиду?

Может это имелось ввиду?

По поводу количества дисков в райдз вроде бы были какие-то циферки рекомендуемые. Не вспомню только, это к райдз относится либо к количеству вдевов. Рекомендую посмотреть поискать.

👍👍 Я вот все как-нибудь хотел бы погонять высоконагруженную Постгрес на зфс, посмотреть, потюнить

Dell вообще считает 5й и аналогии не прод

смотря что считать высоконагруженной базой. у меня если 10к iops снимают - это уже очень неплохо..

Тем не менее в их емс часто 50 при этом 😁

Dell вообще считает 5й и аналогии не прод

смотря что считать высоконагруженной базой. у меня если 10к iops снимают - это уже очень неплохо..

будете смеяться, у dell emc есть схд которая поддерживает только один тип raid - raid5)))

Они ее как домашнюю схд двигают наверное

полный фарш

До 30-50 иопс, куча запросов, плюс вкряченный сбоку биай 😁😁😁 Не спрашивай, как так получилось

Доброго вечера коллеги, я редко работаю с zfs , но года 2,5 назад собрал на freenas массив raidz3 , на нем работают, все хорошо, сегодня я с него черех smb на винде удалил файл в 40ТБ, но как то объем свободного пространства не увеличился, что может быть? корзины у smb - нет

снапшоты могут быть