Умеет ли OpenZFS добавлять в пул dRAID новые диски для расширения пула?

Вот тебе лайфхак - наделай файлов по 100Мб, собери из них пул, да проверяй там что вздумается.

Я такое пробовал с losetup, когда игрался с созданием пула с загрузчиком в нем же.

zfs нет в ядре - это единственная причина по которой ее лучше не пользоваться

zfs нет в ядре

Мне без разницы есть или нет.

В Debian почти есть удобно через DKMS, а в Alpine есть заранее собранный модуль отдельным пакетом.

- это единственная причина по которой ее лучше не пользоваться

Очень смешная причина. Было бы еще смешнее использовать вместо ZFS что-то другое.

Ну а в чём проблема проверить самому нужные команды? Более того, достаточно прочитать ман zpool attach, чтобы догадаться, что расширять raidz и draid нельзя.

Подсоби ребятам (ну или подожди), и будет можно: https://github.com/openzfs/zfs/pull/12225

zfs нет в ядре - это единственная причина по которой ее лучше не пользоваться

Мало ли чего ещё в мире нет в ядре. И почему это является причиной чем-то не пользоваться. Тем более единственной причиной.

Так много вопросов и так мало ответов :)

ШТО?! Какой dmraid? В ZFS своя реализация.

Но ZFS пофиг, она сожрёт любое "устройство" (или даже файл). Вот только если оно у тебя развалится (а оно развалится!), то сам дурак, будь готов бороться.

https://www.reddit.com/r/zfs/comments/vqc0m9/comment/iep23ce/?utm_source=share&utm_medium=web2x&context=3

BTRFS для обычной пекарни предпочтительнее. Его прокачали. Он стал намного быстрее

все эти системы нужны лишь для параноиков типа меня которые боятся удалить безвозвратно что-то нужное, а остальные их возможности как ненужные плюшки… хотя, возможно, и тест сомнительный, но недавно Btrfs и Ext4 в них обогнала

BTRFS для обычной пекарни

Что такое обычная?

предпочтительнее.

Чем? Тем, что он есть в ядре? Не смеши.

Его прокачали.

Силами джунов-копипастеров?

Он стал намного быстрее

Быстрее чего? ZFS мне нужен для быстроты, LOL?

А OpenZFS чьими силами делают по-твоему?

и тест сомнительный, но недавно Btrfs и Ext4 в них обогнала

Самый лучший тест - это история успехов Бытырыфыс в области просера своих пулов, вероятно незабываемый experience, хорошо, что чужой ...

А OpenZFS чьими силами делают по-твоему?

Калифорнийская школота (сарказм) из Ливерморской лаборатории копипастит из твоего бытырыфыс?

ШТО?! Какой dmraid? В ZFS своя реализация.

Дружище, в 2022 году dRAID - это не опечатка!

Но ZFS пофиг, она сожрёт любое «устройство» (или даже файл). Вот только если оно у тебя развалится (а оно развалится!), то сам дурак, будь готов бороться.

За 10 лет ZFS не развалилась и не потеряла ни одного бита данных (дома по крайне мере с учетом сохранности реплик, а в заземленном проде вообще ни одной утери пула или данных) даже под воздействием сильных помех, что я делаю не так?

Чел, ты упорот. В контексте треда ни слова не было про dmraid, сжирание любых устройств, разваливание пула и дураков.

У тебя так смешно подгорает, продолжай, пожалуйста :-)

Устроили представление.

ну ты и упоролся. код от студентов когда-нибудь видел? сколько приставок не добавь…

институт он везде институт. причем, он ни разу не профильный. сидят там люди, которые минзурки должны в будущем протирать что-то говнокодят

Behlendorf или Ahrens? Протирать мензурки, LOL ?

Ты видел, кто там топовые контрибьютеры?

https://github.com/openzfs/zfs/pulse

Уточни хотя бы у Меликова.

ты писал именно про то что ступиденты типа разрабатывают и это типа хорошо, а я же намекнул, что сишнику чтобы научиться программировать нужно лет 10, а за 2-3 и даже за 4 года ступидент ничему не научится во-первых потому что ему по-мимо программирования нужно учебой заниматься всякие gender science посещать и лекции про анальный секс с неграми… то что там среди контрибьютеров есть нормальные мужики с опытом - это, конечно, хорошо, но не отменяет ничего мною вышеописанного

Так в каком популярном открытом проекте нет недавностудней? Главное, чтобы направляли, руководили и ревьювили топовые спецы (а не клоуны) в достаточном количестве.

причем тут это? zfs по производительности отстает от btrfs.

причем тут это? zfs по производительности отстает от btrfs.

Я уже устал повторять, что производительность вообще неинтересна без сохранности данных уровня ZFS. А все потому что ты тролль с регой двухдневной давности, и по сути пиаришь ZFS моими ответами на твои вбросы.

Твоя производительность нужна только для тестовых стэндов с полностью автоматическим IaC и то, только при очень значительном преимуществе процентов на 50-100, иначе нет даже для тестовой среды, чтобы не плодить зоопарк FS.

я старожил который тут обитает лет 5, а ты какой-то школьник с первого курса. у меня BTRFS года 4 ничего не терял

Старожил не троллит своим старожильским акком :)

у меня BTRFS года 4 ничего не терял

твой личный опыт не репрезентабелен.

я старожил который тут обитает лет 5

ну какой ты старожил, ты еще мальчик 😏

ШТО?! Какой dmraid? В ZFS своя реализация.

Дружище, в 2022 году dRAID - это не опечатка!

Сорян, в глаза долблюсь… Я действительно прочитал как dmraid. Регистр же не зря придумали. ☺

Но ZFS пофиг, она сожрёт любое «устройство» (или даже файл). Вот только если оно у тебя развалится (а оно развалится!), то сам дурак, будь готов бороться.

За 10 лет ZFS не развалилась и не потеряла ни одного бита данных (дома по крайне мере с учетом сохранности реплик, а в заземленном проде вообще ни одной утери пула или данных) даже под воздействием сильных помех, что я делаю не так?

У меня тоже. Про «развалится» было именно в контексте скрещивание ежа с ужом (по причине невнимательности).

Причём я знаю что есть dRAID (я бы тоже потыкал, но нет достаточного количества ресурсов для), хоть помочь с этим и не могу — практического опыта нет.

melkor217, ↑, я не упорот, я просто в глаза долблюсь (РЕГИСТР!!!11).

я не упорот, я просто в глаза долблюсь (РЕГИСТР!!!11).

Ну ок, не настаиваю. Я-то вообще не сразу вспомнил, что dmraid это обычный софтварный рейд, и твой посыл был про это всё :)

ну какой ты старожил, ты еще мальчик

а ты девочка?

твой личный опыт не репрезентабелен

будто ты на мир смотришь не со своей колокольни

у zfs единственный плюс - это нативное шифрование, но я не нашел тестов каких-то. а то что оно в ядро не встроено: я тут видел темы про развалившийся zfs и с испорченной btrfs, но считаю то, что разработчики ядра линукса могут сломать что-то после чего ты не сможешь грузиться слишком рискованным

Я-то вообще не сразу вспомнил, что dmraid это обычный софтварный рейд, и твой посыл был про это всё :)

Ну, в Linux софтварный RAID можно реализовать целой пачкой способов, и некоторые линуксоиды упарываются всякими странными вещами, в том числе и RAID в RAID засунуть могут («А что если..?»), у них сбудется. ☺ Причём я не утверждаю что все линуксоиды такие, но их либо немало, либо эти экспериментаторы сильно привлекают внимание.

Во FreeBSD для софтварных RAID помимо ZFS есть gstripe(8) (RAID-0) и gmirror(8) (RAID-1), но никто не пытается скрестить ужа с ежом (а если и пытается, то так, чтобы никто не заметил, ибо последствия очевидны).

у zfs единственный плюс - это нативное шифрование

• Сжатие (не уникально);
• Снапшоты (не уникально);
• Шифрование;
• Репликация;
• Расшаривание (NFS, SMB);
• RAID.

Да, есть файловые системы, которые умеют некоторые из этих плюшек, но.

Целостность - самое главное, вместе со снэпшотами и репликами конечно.

Человеку шашечки, а ты про целостность. ☺

ну, насчет, встроенного шифрования и расшаривания, они, возможно, и не нужны, потому как сторонние средства получше с подобными задачами справляются.

у меня btrfs на сервере, правда там зеркальный рейд еще. начинай бомбить

ну, насчет, встроенного шифрования и расшаривания, они, возможно, и не нужны, потому как сторонние средства получше с подобными задачами справляются.

It depends. Но я по-старинке предпочитаю geli(8).

на сервере

Одноплатник, поди, какой-нибудь…

чужой опыт зачастую более ценен.
подрастешь - поймешь.

у zfs единственный плюс - это нативное шифрование

это самый незначительный плюс.

я тут видел темы про развалившийся zfs

вот прям темы? много?
я может пару припомню, не больше.

и с испорченной btrfs

а вот этого добра точно много.

а у меня raidz2
это типа raid6, в который твой btr так и не научился.

или у тебя btr поверх аппаратного зеркала?

вот сразу видно что ты не расшаривал zfs по smb, nfs и iscsi.

так зачем? я ж написал для пользователя btrfs идеален. да и на сервере тоже. на нем шарить ничего не надо. нужны снапшоты и два диска в зеркальном рейде

Насколько (во сколько раз дороже) сделать из зеркал избыточность сравнимую с raidz3 при большом количестве дисков (например 20 шт.)?

😂

Пардон, но я бы не стал делать raidz3 из 20 дисков
Я бы сделал raidz2+raidz2

А dRAID3 из 20-и дисков для архивных бэкапов, если нет необходимости в высокой скорости работы массива, но требования к его отказоустойчивости максимальные? И вот интересно, что тогда нужно использовать 20/3= примерно 7 отдельных HDD контроллеров для надежности?

Возможно, поэтому действительно лучше около 10-и дисков на один vdev, а именно 9 дисков, для которых хватит 3 контроллера желательно разных хорошо протестированных моделей? Все равно это выгоднее (по объему как 6 рабочих дисков), чем даже двойной mirror (где по объему получится всего 4 отдельных диска, а избыточность намного ниже при плохом раскладе).

Ну понятно, что лучше еще и реплику на таком же втором сервере в другой гео локации.

Т.е. получается, что для более менее обеспеченных пользователей, кто может сразу укомплектовать массив десятью дисками (1 spare), особого смысла и нет в расширении таких vdev добавлением новых дисков? Добавление полезно только для малообеспеченных, кто наращивает свой raidzX пул постепенно по мере возможности.

Интересно, кто-нибудь практикует использование vdev типа dRAID или raidz для сборки больших мульти-vdev пулов для хранения баз данных? Обычно в контексте баз данных говорят про пулы из зеркальных vdev, похожие на RAID10?

А dRAID3 из 20-и дисков для архивных бэкапов

не рекомендуется пихать в один vdev много дисков
макси-оптимальный 😏 вариант для raidzХ: 8+Х
у dRAID, вроде тоже группировка по 8 по дефолту.
на мой взгляд этот тип рейда еще сырой для продакшена, надо подождать когда код отшлифуют.

И вот интересно, что тогда нужно использовать 20/3= примерно 7 отдельных HDD контроллеров для надежности?

а чо не по контроллеру на диск? 😏
у нас в корзинах по 2 контроллера на бэкплейн и двухпортовые диски

Интересно, кто-нибудь практикует использование vdev типа dRAID или raidz для сборки больших мульти-vdev пулов для хранения баз данных?

raidz практикуют.
draid хз, он молод еще 😏

а чо не по контроллеру на диск? 😏

Контроллер может не просто выйти из строя, а по тем или иным причинам (которые устраняются заменой контроллера на другой экземпляр или модель) внезапно начать записывать неправильные данные.

Поэтому, чтобы пул выжил, необходимо, чтобы один поехавший контроллер не мог испортить количество дисков больше чем количество дисков избыточности в vdev пула.

Например, для vdev - зеркала из трех дисков избыточным являются два диска, поэтому один контроллер не может обслуживать более двух дисков такого vdev, но в идеале конечно раскидать все 3 диска зеркального vdev по трем разным контроллерам, причем для других зеркальных vdev в одном общем stripe можно легко задействовать те же самые контроллеры, главное чтобы выжил каждый vdev, неважно на каких одном или двух контроллерах из трех.

Другой пример, raidz3 (или dRAID3) из 9 дисков, где образно (не вдаваясь в суть распределения parity по всем дискам vdev) 6 дисков для данных и 3 диска для избыточности. Чтобы сохранить пул, мы не можем одномоментно потерять более 3х дисков в пуле, значит один поехавший контроллер не должен испортить данные более 3х дисков. Значит нужно на один контроллер цеплять не более 3х дисков одного vdev типа raidz3 из 9-и дисков. Всего у нас 9 дисков / 3 диска = 3 контроллера на один vdev raidz3 из 9-и дисков.

Если бы у нас был raidz3 из 8-ми дисков, то 4 контроллера позволили бы при поехавшем одном контроллере сохранить целой инфу уже на 6 дисках, т.е. в отличии от прошлого примера у нас бы остался живым еще и один резервный диск: 8-6=2 < 3 резервных на 1 диск, т.е. из 6 дисков только 5 будут жизненно необходимыми для vdev, а 6-ой резервным (данные на двух резервных испортятся из-за одного поехавшего контроллера).

у нас в корзинах по 2 контроллера на бэкплейн и двухпортовые диски

Двухпортовые диски находят путь до любого работающего контроллера, но только до какого-то одного, который они выберут, верно? Типа load балансера? Тогда если у одного из твоих контроллеров поедет крыша в raidzХ: 8+Х, то можно потерять инфу на 4+X/2 дисках=4+ дисках = очень вероятно на >=5 дисках (при X>=2). Ессно твой пул такого не переживет, ведь у него избыточность от силы=3 и то наврядли, вероятно лишь raidz2?

PS: тогда вероятно оптимальным конфигом raidz3 является vdev из 8-ми (5+3) дисков и 4-х контроллеров (по два диска на каждый контроллер). Причем один контроллер может обслуживать любое количество vdev одного пула, но в пределах одного vdev не более двух дисков. Золотая середина конфига ? :)

А spare диски в ZFS пуле общие для всего пула, а не только для какого-то одного vdev?