о, там уже и драфт для 2.1.0 завели (пока не в паблике), draid уже близко:)

интересно, а по fr на произвольное изменение конфигурации пула (например удаление любого vdev или изменение размера vdev) что-то движется? в солярке сделали же

вот интересно, собрал пул из 6 зеркал в страйпе. сейчас на него льют данные

-------------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- capacity operations bandwidth total_wait disk_wait syncq_wait asyncq_wait scrub trim pool alloc free read write read write read write read write read write read write wait wait -------------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- s3_1 6,16T 37,4T 3 1,77K 26,4K 1,42G 21ms 185ms 21ms 9ms 1us 924ns - 179ms - - mirror 1,05T 6,21T 0 337 3,20K 255M 37ms 169ms 37ms 8ms 1us 1us - 165ms - - wwn-0x5000cca099ddf22e - - 0 168 0 127M - 170ms - 8ms - 1us - 165ms - - wwn-0x5000cca099ddf404 - - 0 168 3,20K 128M 37ms 169ms 37ms 8ms 1us 816ns - 164ms - - mirror 1,02T 6,24T 0 318 1,60K 238M 50ms 165ms 50ms 9ms 1us 768ns - 161ms - - wwn-0x5000cca252d436db - - 0 159 1,60K 120M 50ms 188ms 50ms 9ms 1us 672ns - 183ms - - wwn-0x5000cca252d438a8 - - 0 158 0 118M - 143ms - 9ms - 864ns - 139ms - - mirror 1,02T 6,25T 1 298 7,99K 238M 17ms 184ms 17ms 9ms 2us - - 174ms - - wwn-0x5000cca252d4435f - - 0 150 2,40K 119M 31ms 196ms 31ms 10ms 1us - - 186ms - - wwn-0x5000cca252d4442e - - 0 148 5,59K 119M 10ms 172ms 10ms 9ms 2us - - 162ms - - mirror 1,03T 6,24T 0 280 4,80K 246M 14ms 212ms 14ms 10ms 1us 1us - 208ms - - wwn-0x5000cca252d444f8 - - 0 140 2,40K 123M 9ms 229ms 9ms 10ms 2us 1us - 224ms - - wwn-0x5000cca26bc943b3 - - 0 140 2,40K 123M 18ms 195ms 18ms 10ms 1us 864ns - 192ms - - mirror 1,02T 6,25T 0 280 4,00K 243M 33ms 207ms 33ms 10ms 2us 780ns - 196ms - - wwn-0x5000cca26bcc8c38 - - 0 139 0 121M - 234ms - 10ms - 840ns - 216ms - - wwn-0x5000cca26bcd7f5d - - 0 140 4,00K 121M 33ms 179ms 33ms 10ms 2us 720ns - 176ms - - mirror 1,02T 6,24T 0 293 4,80K 237M 12ms 181ms 12ms 9ms 1us 864ns - 178ms - - wwn-0x5000cca26bdf9edf - - 0 146 1,60K 118M 25ms 187ms 25ms 10ms 1us 979ns - 186ms - - wwn-0x5000cca26be339be - - 0 147 3,20K 119M 8ms 175ms 8ms 9ms 2us 748ns - 171ms - - -------------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----

конфигурация пула

pool: s3_1 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM s3_1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 wwn-0x5000cca099ddf22e ONLINE 0 0 0 wwn-0x5000cca099ddf404 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 wwn-0x5000cca252d436db ONLINE 0 0 0 wwn-0x5000cca252d438a8 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 wwn-0x5000cca252d4435f ONLINE 0 0 0 wwn-0x5000cca252d4442e ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 wwn-0x5000cca252d444f8 ONLINE 0 0 0 wwn-0x5000cca26bc943b3 ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 wwn-0x5000cca26bcc8c38 ONLINE 0 0 0 wwn-0x5000cca26bcd7f5d ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 wwn-0x5000cca26bdf9edf ONLINE 0 0 0 wwn-0x5000cca26be339be ONLINE 0 0 0 errors: No known data errors

1.5 Гб/сек это много или мало?) люди получили схожие результаты на xfs на аппаратном raid10, но латенси у них доходила до 250 ms. а тут пока в районе 150 ms

1.5 Гб/сек это много или мало?) люди получили схожие результаты на xfs на аппаратном raid10, но латенси у них доходила до 250 ms. а тут пока в районе 150 ms

sync какой?

sync какой?

disable

disable

ну так это не продуктивный режим. эти цифры не о чем

тут 100% последовательная запись блоком по 1 Мб. recordsize = 1 mb, compression=lz4

ну так это не продуктивный режим. эти цифры не о чем

в чем его непродуктивность? аппаратный raid писал в режиме write-back ежли что.

тут 100% последовательная запись блоком по 1 Мб. recordsize = 1 mb, compression=lz4

но, при записи не надо ждать подтверждения. вот тебе и латеси

в чем его непродуктивность? аппаратный raid писал в режиме write-back ежли что.

что за рейд?

но, при записи не надо ждать подтверждения. вот тебе и латеси

карточка какая-то, модели не знаю к сожалению, могу уточнить.

карточка какая-то, модели не знаю к сожалению, могу уточнить.

просто может там совсем кака. хотя признаем: свежесозданый пул, как правило довольно быстрый

а вот сравнить бы его через год

просто может там совсем кака. хотя признаем: свежесозданый пул, как правило довольно быстрый

тааак))) но соглашусь.. у меня будет шанс увидеть как этот пул забьется процентов на 90%. в случае с xfs деградация по записи была..

а вот сравнить бы его через год

zfs тоже имеет фрагментацию и тоже страдает при заполнении. больше чем на 90% точно..

zfs тоже имеет фрагментацию и тоже страдает при заполнении. больше чем на 90% точно..

да даже при повторном заполнении vdev скорость записи проседает

тааак))) но соглашусь.. у меня будет шанс увидеть как этот пул забьется процентов на 90%. в случае с xfs деградация по записи была..

при 90% зфс вообще шляпа :)))

да даже при повторном заполнении vdev скорость записи проседает

будет возможность сравнить.

просто может там совсем кака. хотя признаем: свежесозданый пул, как правило довольно быстрый

MegaRAIDSAS9361-4i - вполне нормальный адаптер

MegaRAIDSAS9361-4i - вполне нормальный адаптер

не помню, а там при создании 10 рейда билд идет? не могло попасть что в это время билд был и вы тестили?

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

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

ну я предположил. а вообще инициализации вляет. по крайней мере, контроллеры об этом предупреждают

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

распределение по блокам

s3_1 sync_read sync_write async_read async_write scrub trim req_size ind agg ind agg ind agg ind agg ind agg ind agg ---------- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- 512 0 0 0 0 0 0 0 0 0 0 0 0 1K 0 0 0 0 0 0 0 0 0 0 0 0 2K 0 0 0 0 0 0 0 0 0 0 0 0 4K 0 0 19 0 0 0 147 0 0 0 0 0 8K 1 0 0 0 0 0 10 28 0 0 0 0 16K 0 0 0 0 0 0 2 23 0 0 0 0 32K 0 0 0 0 0 0 5 30 0 0 0 0 64K 0 0 0 0 0 0 3 3 0 0 0 0 128K 0 0 0 0 0 0 0 0 0 0 0 0 256K 0 0 0 0 0 0 30 4 0 0 0 0 512K 0 0 0 0 0 0 0 52 0 0 0 0 1M 0 0 0 0 0 0 1,12K 0 0 0 0 0 2M 0 0 0 0 0 0 0 0 0 0 0 0 4M 0 0 0 0 0 0 0 0 0 0 0 0 8M 0 0 0 0 0 0 0 0 0 0 0 0 16M 0 0 0 0 0 0 0 0 0 0 0 0 ----------------------------------------------------------------------------------------------

1.5 Гб/сек это много или мало?) люди получили схожие результаты на xfs на аппаратном raid10, но латенси у них доходила до 250 ms. а тут пока в районе 150 ms

1.5/6~= 250м/сек на зеркало, это hdd? если да, то отлично

да, это hdd NL-SAS от тошиба, 8 Тб.

да, это hdd NL-SAS от тошиба, 8 Тб.

я бы сказал что оба варианта смогли утилизировать диски полностью, но zfs за счёт аггрегации записи может линейно записать

отсюда меньшее латенси

я бы сказал что оба варианта смогли утилизировать диски полностью, но zfs за счёт аггрегации записи может линейно записать

вообще при такой линейной нагрузке я ожидаю что с диска (а не с миррора) можно выжать до 200 Мб/с на запись, посмотрим как пойдет, нагрузка со стороны приклада будет расти

вообще при такой линейной нагрузке я ожидаю что с диска (а не с миррора) можно выжать до 200 Мб/с на запись, посмотрим как пойдет, нагрузка со стороны приклада будет расти

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

а вот чтение да, может утилизировать оба

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

вот тут мне непонятен вывод iostat, если он показывает что

mirror 1,05T 6,21T 0 337 3,20K 255M 37ms 169ms 37ms 8ms 1us 1us - 165ms - - wwn-0x5000cca099ddf22e - - 0 168 0 127M - 170ms - 8ms - 1us - 165ms - - wwn-0x5000cca099ddf404 - - 0 168 3,20K 128M 37ms

значит на каждый диск реально пишется в районе 125-130 Мб/с, верно? соот-но 250 на mirror.

соот-но если на каждый диск будет писаться по 200 мб/с, то с миррора - 400 Мб/с?

вот тут мне непонятен вывод iostat, если он показывает что

а, тю, не всмотрелся и на вашу цифру отреагировал, 1.5Г это суммарная запись на диски, делите на 2, у вас каждый диск по 120М/сек принимать может, выглядит реальной цифрой относительно 250м)

если что - я смотрю нагрузку другими утилитами, например dstat

[root@s3 root]# dstat You did not select any stats, using -cdngy by default. ----total-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai stl| read writ| recv send| in out | int csw 22 8 66 3 0| 0 1561M| 12k 12k| 0 0 | 154k 316k 24 8 64 3 0| 32k 1431M|8957B 8969B| 0 0 | 156k 316k 21 8 67 3 0| 16k 1152M| 13k 12k| 0 0 | 152k 319k 27 10 58 2 0|8192B 1140M| 16k 17k| 0 0 | 165k 551k 27 10 60 2 0| 31k 1003M| 18k 18k| 0 0 | 176k 725k 27 6 63 2 0| 0 1372M|9645B 9690B| 0 0 | 169k 718k 23 9 62 5 0| 24k 1520M|9488B 9508B| 0 0 | 158k 387k 22 8 66 3 0|8194B 1498M| 11k 11k| 0 0 | 149k 312k 25 8 64 2 0| 24k 1117M| 16k 16k| 0 0 | 146k 303k 22 8 66 3 0| 32k 1202M| 19k 19k| 0 0 | 151k 314k 23 5 69 2 0|8194B 938M| 14k 14k| 0 0 | 153k 327k 24 5 64 5 0| 32k 1345M| 17k 17k| 0 0 | 150k 313k 21 8 67 3 0|8190B 1535M| 19k 19k| 0 0 | 152k 316k 25 8 63 3 0|8194B 1556M| 15k 15k| 0 0 | 148k 305k 24 8 63 4 0|8192B 1507M| 61k 60k| 0 0 | 159k 316k 21 8 68 2 0| 0 1177M| 12k 12k| 0 0 | 154k 319k^C

видим те же самый 1.5 Гб/с. по идее запас еще есть..

если что - я смотрю нагрузку другими утилитами, например dstat

iostat -x 5 покажите к примеру

именно iostat а не zpool iostat

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sda 1,60 449,00 1,60 104279,20 0,00 0,40 0,00 0,09 31,62 7,30 3,33 1,00 232,25 1,33 60,14 sdf 1,60 451,20 1,60 113930,40 0,00 0,00 0,00 0,00 31,88 7,55 3,46 1,00 252,51 1,33 60,04 sdj 2,00 413,40 3,20 103574,40 0,00 0,00 0,00 0,00 18,70 6,89 2,89 1,60 250,54 1,21 50,10 sdg 2,20 409,00 3,20 98359,20 0,00 0,00 0,00 0,00 36,45 7,34 3,08 1,45 240,49 1,42 58,56 sdh 1,60 453,60 0,00 104340,80 0,00 0,00 0,00 0,00 23,12 6,97 3,20 0,00 230,03 1,26 57,22 sdd 1,40 420,20 1,60 101105,60 0,00 0,20 0,00 0,05 53,57 7,20 3,10 1,14 240,61 1,37 57,92 sdl 2,00 450,40 4,80 104279,20 0,00 0,00 0,00 0,00 19,80 6,71 3,06 2,40 231,53 1,25 56,64 sdk 1,20 421,00 1,60 101105,60 0,00 0,20 0,00 0,05 14,67 7,35 3,11 1,33 240,16 1,25 52,78 sdc 1,80 413,00 1,60 103574,40 0,00 0,00 0,00 0,00 30,78 7,28 3,06 0,89 250,79 1,30 54,04 sdi 1,80 451,20 3,20 113930,40 0,00 0,00 0,00 0,00 25,11 7,51 3,43 1,78 252,51 1,31 59,30 sdb 2,00 451,60 2,40 104340,80 0,00 0,00 0,00 0,00 23,10 7,26 3,33 1,20 231,05 1,32 59,72 sde 2,20 409,60 4,80 98359,20 0,00 0,00 0,00 0,00 47,09 7,33 3,11 2,18 240,13 1,39 57,06 sdm 0,00 6,00 0,00 26,20 0,00 0,20 0,00 3,23 0,00 0,63 0,00 0,00 4,37 0,63 0,38 sdn 0,00 6,00 0,00 26,20 0,00 0,20 0,00 3,23 0,00 0,63 0,00 0,00 4,37 0,60 0,36 md127 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 md126 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 md125 0,00 5,00 0,00 25,60 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 5,12 0,00 0,00

как то так.. хм.. почему то системный iostat показывает размер блока на запись = 250 Кб.. а zpool iostat - 1 Мб..

это не может быть по причине аггрегации блоков в памяти перед сбросом на диски? в соответствии с заданным recordsize?

как то так.. хм.. почему то системный iostat показывает размер блока на запись = 250 Кб.. а zpool iostat - 1 Мб..

zpool iostat показывает размер блока который он внутри себя оперировал, как оно на диск попадёт - зависит от метода его подключения и тд и тп

zpool iostat показывает размер блока который он внутри себя оперировал, как оно на диск попадёт - зависит от метода его подключения и тд и тп

а можно немного детальнее? метод подключения это что? я почему интересуюсь. мне сказали что будут писать большими блоками, соот-но я задал recsize=1 Мб для датасета. может имеет смысл подтюнить и задать 256к?

а можно немного детальнее? метод подключения это что? я почему интересуюсь. мне сказали что будут писать большими блоками, соот-но я задал recsize=1 Мб для датасета. может имеет смысл подтюнить и задать 256к?

нет, уменьшать смысла нет, если пишут таким блоком

как диски подключены? hba?

да

точнее raid контроллер в режиме jbod

точнее raid контроллер в режиме jbod

jbod - такое себе решение.

jbod - такое себе решение.

почему? в этом режиме диски пробрасываются в систему as is, что собственно и рекомендуется. я не нашел пока логических объяснений утверждениям что обычнй hba лучше (в чем лучше?) чем riad в режиме jbod

почему? в этом режиме диски пробрасываются в систему as is, что собственно и рекомендуется. я не нашел пока логических объяснений утверждениям что обычнй hba лучше (в чем лучше?) чем riad в режиме jbod

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

я пока не нашел логических утверждений чем вообще плохо рейд пробросить

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

так это проблема не контроллера, а кривого диска

так это проблема не контроллера, а кривого диска

с hba такого поведения нет

на зфс дохлый диск тоже раком систему ставит

с hba такого поведения нет

лично наблюдал дикие тормоза

почему? в этом режиме диски пробрасываются в систему as is, что собственно и рекомендуется. я не нашел пока логических объяснений утверждениям что обычнй hba лучше (в чем лучше?) чем riad в режиме jbod

raid обычно - более сложная железка со соей логикой, доп логика обычно требует ресурсов. Если он позволяет честно пробросить диск полностью в режиме jbod - норм. Но смысла в доп логике ненужной мало и более дешёвый hba обычно эффективнее и быстрее. Это вся разница

лично наблюдал дикие тормоза

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

с hba такого поведения нет

с hba lsi 9305 у меня валились ошибки по всем дискам в пуле (disk timeout например). zfs считал что диски сбойные и помечал их как degraided и failed. пока не прошил на самую свежую версию прошивки - пул сыпался..

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

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

raid обычно - более сложная железка со соей логикой, доп логика обычно требует ресурсов. Если он позволяет честно пробросить диск полностью в режиме jbod - норм. Но смысла в доп логике ненужной мало и более дешёвый hba обычно эффективнее и быстрее. Это вся разница

в своих тестах не видел разницы по скорости между hba и jbod raid.. но сам при этом рекомендую брать именно hba) ладно, это достаточно специфичная тема.

в этом, кстати отличе рейдовых веников

в своих тестах не видел разницы по скорости между hba и jbod raid.. но сам при этом рекомендую брать именно hba) ладно, это достаточно специфичная тема.

А какую модель HBA?

в этом, кстати отличе рейдовых веников

вроде можно таже tler включать на каких-то вениках

raid обычно - более сложная железка со соей логикой, доп логика обычно требует ресурсов. Если он позволяет честно пробросить диск полностью в режиме jbod - норм. Но смысла в доп логике ненужной мало и более дешёвый hba обычно эффективнее и быстрее. Это вся разница

вы лучше скажите, я прав в своем предположении что определенный запас у моей конфигурации по Mb/s есть? понятно что будет расти latency, но в данном кейсе это не критично пока bandwidth устраивает

в своих тестах не видел разницы по скорости между hba и jbod raid.. но сам при этом рекомендую брать именно hba) ладно, это достаточно специфичная тема.

пока по спекам raid тянет. Я просто гонял полку на 104 чтоли диска, там оч быстро и в pci-e линии упираешься, и в производительность hba. У raid-железки за бОльшие деньги спека может быть хуже. Пока тянет - норм

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

кто именно будет елозить?)

вы лучше скажите, я прав в своем предположении что определенный запас у моей конфигурации по Mb/s есть? понятно что будет расти latency, но в данном кейсе это не критично пока bandwidth устраивает

небольшой запас, в лучшем случае ещё х1.5

кто именно будет елозить?)

диск.

диск.

в zfs пуле?

А какую модель HBA?

lsi 9305

в zfs пуле?

какая разница диску какой там пул. он получил команду прочитать. он десктопный и не знает что там еще пачка копий, он пытается читать и не переходит дальше

небольшой запас, в лучшем случае ещё х1.5

1.5 это было бы совсем хоршо.