Raidz?

Да. 4 по 18

Да. 4 по 18

Zpool list для raidz пишет сырое место

Zpool list для raidz пишет сырое место

А, с учетом четности. Понял, буду знать

А, с учетом четности. Понял, буду знать

Ага, плюс стоит иметь в виду влияние размера блока на эффективность утилизации для raidz

Ну это уже мелочи. Суть ясна.

А вот еще вопрос. Сколько максимально дисков может быть в raidz и в raidz2? Как лучше раскидать 14 дисков - raid60? raidz2?

Я бы сделал пул из рейд1 вдев

А вот еще вопрос. Сколько максимально дисков может быть в raidz и в raidz2? Как лучше раскидать 14 дисков - raid60? raidz2?

Ограничение по коду 240 чтоли на 1 вдев:) на практике стоит отталкиваться от потребностей по производительности, больше 10 дисков на вдев стоит делать только осознавая ограничения по перформансу.

Ограничение по коду 240 чтоли на 1 вдев:) на практике стоит отталкиваться от потребностей по производительности, больше 10 дисков на вдев стоит делать только осознавая ограничения по перформансу.

Ага, то есть, 12-14 дисков имеет смысл уже в raidz2+0

Ага, то есть, 12-14 дисков имеет смысл уже в raidz2+0

если нужна производительность, то только рейд из зеркал. This is a way. У меня например такой пул есть: NAME STATE READ WRITE CKSUM bpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 scsi-35000c50041152dc7 ONLINE 0 0 0 scsi-35000cca01b8186bc ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 scsi-35000cca01b818a08 ONLINE 0 0 0 scsi-35000cca01b818740 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 scsi-35000c50041158d93 ONLINE 0 0 0 scsi-35000c500410c7e1b ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 scsi-35000cca01b818df4 ONLINE 0 0 0 scsi-35000cca01b81871c ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 scsi-35000cca01b818504 ONLINE 0 0 0 scsi-35000cca01b8186c8 ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 scsi-35000c500410c1a17 ONLINE 0 0 0 scsi-35000c50042537393 ONLINE 0 0 0

Ага, то есть, 12-14 дисков имеет смысл уже в raidz2+0

А все рейдZ это чисто хранилки, причём ориентированные на чтение, так как прироста к записи почти нет. Хотя можно прикрутить NVME SSD под кэш, у ZFS есть такая фича И ещё минус у рейдZ - плохая расширяемость, точнее её отсутствие по сути. Увеличивать единожды созданный рейдZ пул можно только путём подмены дисков на более ёмкие.

А все рейдZ это чисто хранилки, причём ориентированные на чтение, так как прироста к записи почти нет. Хотя можно прикрутить NVME SSD под кэш, у ZFS есть такая фича И ещё минус у рейдZ - плохая расширяемость, точнее её отсутствие по сути. Увеличивать единожды созданный рейдZ пул можно только путём подмены дисков на более ёмкие.

raid10 - штука, мягко говоря, не очень эффективная в смысле использования дискового пространства. Плохая расширяемость - понятно. Отсутствие прироста к записи - понятно. Я размышляю над вариантом на 14 дисков: один raid, 2 четности или 2 рейда по 7, те же 2 четности?...

Главное достоинство второго варианта - можно заменять диски на более емкие в два подхода

Хотя он и производительнее должен быть (или нет?)

raid10 - штука, мягко говоря, не очень эффективная в смысле использования дискового пространства. Плохая расширяемость - понятно. Отсутствие прироста к записи - понятно. Я размышляю над вариантом на 14 дисков: один raid, 2 четности или 2 рейда по 7, те же 2 четности?...

рейд10 самый дорогущий, да... Но и самый производительный и беспроблемный Два склееных vdev типа рейдZ будут производительнее конечно, чем один большой vdev типа рейдZ, запись по идее удвоится. Но это всё равно слезы. У рейдZ запись ведь равна записи одного диска. У склееного будет запись как у двух дисков, всё равно мало! Расширяемость рейдZ сейчас такая: искусственно выбиваешь один диск, зфс начинает орать, ты ей суешь диск побольше, ждёшь пока она его отресильверит. Далее повторяешь это с каждым диском. Очень нудный процесс. Да и рискованный. И как видишь кол-во vdev его ускоряет только в том плане, что можно это процедуру проделывать одновременно в каждом из vdev И заметь с рейд10 ты "потеряешь" 7 дисков из 14. А с двойным рейддZ2 потеря будет 4 диска. Разница в три диска. Я бы задумался...

рейд10 самый дорогущий, да... Но и самый производительный и беспроблемный Два склееных vdev типа рейдZ будут производительнее конечно, чем один большой vdev типа рейдZ, запись по идее удвоится. Но это всё равно слезы. У рейдZ запись ведь равна записи одного диска. У склееного будет запись как у двух дисков, всё равно мало! Расширяемость рейдZ сейчас такая: искусственно выбиваешь один диск, зфс начинает орать, ты ей суешь диск побольше, ждёшь пока она его отресильверит. Далее повторяешь это с каждым диском. Очень нудный процесс. Да и рискованный. И как видишь кол-во vdev его ускоряет только в том плане, что можно это процедуру проделывать одновременно в каждом из vdev И заметь с рейд10 ты "потеряешь" 7 дисков из 14. А с двойным рейддZ2 потеря будет 4 диска. Разница в три диска. Я бы задумался...

"выбиваешь диск" - а зачем? zpool replace делает все, что нужно, без заметной потери скорости рейда и без риска навернуть все

"выбиваешь диск" - а зачем? zpool replace делает все, что нужно, без заметной потери скорости рейда и без риска навернуть все

а, да? Не знал если честно про такую фичу

рейд10 самый дорогущий, да... Но и самый производительный и беспроблемный Два склееных vdev типа рейдZ будут производительнее конечно, чем один большой vdev типа рейдZ, запись по идее удвоится. Но это всё равно слезы. У рейдZ запись ведь равна записи одного диска. У склееного будет запись как у двух дисков, всё равно мало! Расширяемость рейдZ сейчас такая: искусственно выбиваешь один диск, зфс начинает орать, ты ей суешь диск побольше, ждёшь пока она его отресильверит. Далее повторяешь это с каждым диском. Очень нудный процесс. Да и рискованный. И как видишь кол-во vdev его ускоряет только в том плане, что можно это процедуру проделывать одновременно в каждом из vdev И заметь с рейд10 ты "потеряешь" 7 дисков из 14. А с двойным рейддZ2 потеря будет 4 диска. Разница в три диска. Я бы задумался...

Три диска из 14. Ты готов, например, потерять 20% от зарплаты?...

Три диска из 14. Ты готов, например, потерять 20% от зарплаты?...

ммм, нет🙂

ммм, нет🙂

Так что - разница до фига заметная. При цене 18-тб диска в 15 тысяч рублей, это сотка.

А все рейдZ это чисто хранилки, причём ориентированные на чтение, так как прироста к записи почти нет. Хотя можно прикрутить NVME SSD под кэш, у ZFS есть такая фича И ещё минус у рейдZ - плохая расширяемость, точнее её отсутствие по сути. Увеличивать единожды созданный рейдZ пул можно только путём подмены дисков на более ёмкие.

та ладно, добавляешь еще один рейдЗ и удаляешь старый

Так что - разница до фига заметная. При цене 18-тб диска в 15 тысяч рублей, это сотка.

ну так-то да... Но вот вопрос, сколько времени замёт ресильвер такого большого диска. Я бы наверное при таких раскладах собрал рейдZ3, а для записи прикрутил порядочный NVME SSD небольшого объёма Итого 11 дисков пошло бы в дело

та ладно, добавляешь еще один рейдЗ и удаляешь старый

я не пон, а из чего я ешё один рейд соберу?

ресильвер, это пожалуй единственное, что быстрое у зфс, и то, если переменные подкрутить

я не пон, а из чего я ешё один рейд соберу?

ну вот у тебя есть 10 дисков по 2тб, ты хочешь заменить все на 8тб. добавляешь 10 дисков по 8тб в доп vdev на raidz и потом первому даешь команду ремув. ну и дальше идешь бухать

ну вот у тебя есть 10 дисков по 2тб, ты хочешь заменить все на 8тб. добавляешь 10 дисков по 8тб в доп vdev на raidz и потом первому даешь команду ремув. ну и дальше идешь бухать

а, дошло) Ну, пока расширение к зфс не присобачат наконец, ты имеешь полное право так прикалываться)

ну вот у тебя есть 10 дисков по 2тб, ты хочешь заменить все на 8тб. добавляешь 10 дисков по 8тб в доп vdev на raidz и потом первому даешь команду ремув. ну и дальше идешь бухать

хотя кстати объяснялки Оракл кажется ровно такие и были всегда, что мол серьёзные дяди никогда не будут заниматься такой опасной фигнёй как расширение рейда, так как замедление СХД и риски стоят дороже, чем просто сборка нового большого рейда.

хотя кстати объяснялки Оракл кажется ровно такие и были всегда, что мол серьёзные дяди никогда не будут заниматься такой опасной фигнёй как расширение рейда, так как замедление СХД и риски стоят дороже, чем просто сборка нового большого рейда.

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

а да, работает только на зфс от серьезных дядек из оракл

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

хочу как в всан: добавил диск - добавилось место. сдох диск - места стало меньше, через час произошел ребаланс

хочу как в всан: добавил диск - добавилось место. сдох диск - места стало меньше, через час произошел ребаланс

А ценник как у всан ты не хочешь конечно)

А ценник как у всан ты не хочешь конечно)

я с 90х годов айтишню, мою карму уже ничем не испортить) намек понятен?)

я с 90х годов айтишню, мою карму уже ничем не испортить) намек понятен?)

Вроде да)

у меня и зфсом рулит не фри ос)

А все рейдZ это чисто хранилки, причём ориентированные на чтение, так как прироста к записи почти нет. Хотя можно прикрутить NVME SSD под кэш, у ZFS есть такая фича И ещё минус у рейдZ - плохая расширяемость, точнее её отсутствие по сути. Увеличивать единожды созданный рейдZ пул можно только путём подмены дисков на более ёмкие.

Кто мешает добавить в пул новый vdev?

Подскажите по команде zpool import Допустим сняли с одного сервера диски, поставили во второй, делаем zpool import main Типо он должен воссоздать этот пул? Откуда он берет данные о том что пул вообще кодато существовал, из первых секторов дисков?

Не воссоздать, а подключить. Из суперблоков он берет информацию, их несколько

Подскажите по команде zpool import Допустим сняли с одного сервера диски, поставили во второй, делаем zpool import main Типо он должен воссоздать этот пул? Откуда он берет данные о том что пул вообще кодато существовал, из первых секторов дисков?

С дисков, в принципе вам без разницы откуда

Кто мешает добавить в пул новый vdev?

ну допустим пул рейдZ3 из 14 дисков по 18ТБ у меня. Доступная ёмкость получается 198ТБ Понадобилось ещё 36ТБ Мои варианты?

Добавьте vdev из трёх по 18 тб в raidz1 например

А в целом П - планирование

В проприетарных схд далеко не везде можно по 3 диска добавлять, даже при возможности расширять raid group

кстати ктонить посоветует статью по тому, как раидz3 устроен? как четность считается в parity raid -- очевидно, как она считается в raid6/raidz2(2 разных четности) тоже читал статью. а как сделано в raidz3?

кстати ктонить посоветует статью по тому, как раидz3 устроен? как четность считается в parity raid -- очевидно, как она считается в raid6/raidz2(2 разных четности) тоже читал статью. а как сделано в raidz3?

А где про вторую почитать можно ?) я только про xor знаю

А где про вторую почитать можно ?) я только про xor знаю

кстати ктонить посоветует статью по тому, как раидz3 устроен? как четность считается в parity raid -- очевидно, как она считается в raid6/raidz2(2 разных четности) тоже читал статью. а как сделано в raidz3?

надо отметить что raid6 и raidz2 не являются аналогами, как впрочем и raid5 vs raidz1

про raidz3 и triple raid не изучал, было бы интересно сравнить

надо отметить что raid6 и raidz2 не являются аналогами, как впрочем и raid5 vs raidz1

то есть в raidz1 не чётность (ксор всех блоков с данными) а чтото другое?

я именно про расчёт доп блоков 'четности', а не про то как они по дискам рассыпаются

то есть в raidz1 не чётность (ксор всех блоков с данными) а чтото другое?

да, как я помню там не классический xor

надо найти где я про это читал..

да, как я помню там не классический xor

если честно не вижу смысла делать не ксор. из факта отсутствия диска (классический рейд5) или вдобавок несовпадения чексумы блока (zfs) делается вывод о том какой из n+1 блоков пропал, далее очевидным образом восстанавливается из оставшихся

если честно не вижу смысла делать не ксор. из факта отсутствия диска (классический рейд5) или вдобавок несовпадения чексумы блока (zfs) делается вывод о том какой из n+1 блоков пропал, далее очевидным образом восстанавливается из оставшихся

в zfs для каждого блока вычисляется хэш, чего не делает классический xor в raid5 или двойной xor в raid6

ну вот у тебя есть 10 дисков по 2тб, ты хочешь заменить все на 8тб. добавляешь 10 дисков по 8тб в доп vdev на raidz и потом первому даешь команду ремув. ну и дальше идешь бухать

в openzfs remove на пуле с raidz не работает

в openzfs remove на пуле с raidz не работает

а, ниже отметили, гуд

если честно не вижу смысла делать не ксор. из факта отсутствия диска (классический рейд5) или вдобавок несовпадения чексумы блока (zfs) делается вывод о том какой из n+1 блоков пропал, далее очевидным образом восстанавливается из оставшихся

https://www.klennet.com/notes/2019-07-04-raid5-vs-raidz.aspx - вот тут описаны особенности и отличия

в zfs для каждого блока вычисляется хэш, чего не делает классический xor в raid5 или двойной xor в raid6

ну я об этом и сказал. и это не отменяет обязанности такого рейда все же восстанавливаться инфу если 1 блок пропал или чексум не сошелся )

https://www.klennet.com/notes/2019-07-04-raid5-vs-raidz.aspx - вот тут описаны особенности и отличия

и там ни слова о том как щитается 'triple parity' в z3

ну я об этом и сказал. и это не отменяет обязанности такого рейда все же восстанавливаться инфу если 1 блок пропал или чексум не сошелся )

эм.. так с этим никто не спорил вроде) у raidz еще несколько фич, почитайте ссылку выше

да я ее читал давно уже и про те фичи в курсе )

и даже натурно их испытывал )

и там ни слова о том как щитается 'triple parity' в z3

а я и не обещал что-то про raidz3, выше писал что не изучал этот вопрос

да я ее читал давно уже и про те фичи в курсе )

тогда о чем мы вообще?)

о том как щитается triple parity в z3

о том как щитается triple parity в z3

Может там везде обычный ксор

Так и не понял смысла считать по разному

Может там везде обычный ксор

даже в raid6 уже не обычный ксор в другой 'четности'

Так и не понял смысла считать по разному

вот у тебя было 4 диска из них 2 с одинаковым ксором. сдохло 2 тех что с данными. итого у тебя осталось 2 одинаковых ксора и никаких данных )

В zfs вроде можно указать делать копии?

Привет. Как можно удалить zvol который раздается фряшным таргетом CTL, не выключая сам таргет? К слову я сейчас использую: ctladm remove -b block -l $n, но это не очень красивый метод, и иногда он подвисает.

Странно, я знаю людей, и сам на фряхе использовал. Работало как часы. В день десятки созданий/удалений

Странно, я знаю людей, и сам на фряхе использовал. Работало как часы. В день десятки созданий/удалений

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

вот у тебя было 4 диска из них 2 с одинаковым ксором. сдохло 2 тех что с данными. итого у тебя осталось 2 одинаковых ксора и никаких данных )

Хм. Логично. Убедил

вот у тебя было 4 диска из них 2 с одинаковым ксором. сдохло 2 тех что с данными. итого у тебя осталось 2 одинаковых ксора и никаких данных )

Нет, в raid5 и raid6 данные размазываются по всем дискам, как и parity

Не надо путать с raid4 например

Нет, в raid5 и raid6 данные размазываются по всем дискам, как и parity

да. неважно что они в разных страйпах по-разному размазываются. важно что в одном страйпе — N дисков имеют свои кусочки данных, N+1 диск имеет xor-сумму, N+2 (для r6) сумму описанную в стаье выше

речь о том что суммы на N+1 и N+2 разные

а разные для того чтобы выпадение любых двух дисков еще позволяло восстановить данные

да. неважно что они в разных страйпах по-разному размазываются. важно что в одном страйпе — N дисков имеют свои кусочки данных, N+1 диск имеет xor-сумму, N+2 (для r6) сумму описанную в стаье выше

Соот-но описанная вами выше ситуация когда два диска с данными умерли и остались только диски с parity при использовании raid5 или raid6 невозможна

Соот-но описанная вами выше ситуация когда два диска с данными умерли и остались только диски с parity при использовании raid5 или raid6 невозможна

прекрасно возможна