не собирается vdev без зеркала

50ГБ

и пепед созданием файла: zfs set recordsize=16k ... Протестировать, затем zfs set checksum=off ...

Со специальным vdev тмпа dedup. Наэто устройство упадет очень много записи и по iops и по объёму, возможно в 100 раз брльше записанных данных. Мой опыт показал, что при коэффициеете сжатия 2.5х и дедупликации в районе 3х при использовании зеркала из sata intel s3700 можно записывать данные со скоростью ~100Мбит/сек до сжатия и дедупликации, а при использовании в качестве vdev dedup накопителя nvme intel optane 900P или 905P (500 000 iops на запись), скорость записи будет около 1ГБит в секунду (100МБ в сек)

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

хоть бы зеркало с зеркалом сравнивали или raid10. raid5 и raidz1 довольно разные.

просто у меня сомнения - возможно ли выжать из данного сетапа еще IOPs в случайном чтении или это потолок для дисков. сравнивая с "простым" программным raid - я начал сомневаться

С отклбченными суммами долдно быть быстрее

просто у меня сомнения - возможно ли выжать из данного сетапа еще IOPs в случайном чтении или это потолок для дисков. сравнивая с "простым" программным raid - я начал сомневаться

в параметрах FIO тоже 16к использовать?

просто у меня сомнения - возможно ли выжать из данного сетапа еще IOPs в случайном чтении или это потолок для дисков. сравнивая с "простым" программным raid - я начал сомневаться

Прошу прощение за опечатки. Hakers keybord на андройде имеет очень маленькие клавиши. Постоянно промахиваюсь.

Но zfs в попугаях всегда утупала голому железу. Дело не в максимуме попугаев. Потрея попугаев не бесплатна. Как я писал выше, на реальной нагрузке zfs уменьшает iops сваливающиеся на устройства на порядок или больше. второй момент снимки, третий контрольные суммы, котопых нет в рейде. Если диск начал выдавать кривые данные, софтрейд поубивает всё, а зфс покажет проблему и продержится до замены диска, а если непродержится, то покажет в каких фацлах ошибки.

я поэтому и обратился к коллегам - из-за нехватки опыта - оценить насколько мои выводы верны

сегодя весь день тестирую dedup vdev. пул: raidz2 из 8 жестких дисков + 1 ssd под dedup recordsize=256k методика тестирования: из /dev/urandom с помощью dd генерится мусор и блоками по 1М пишется в пул. скорость генерации/записи сырого мусора пока что стабильна и составляет 198 MB/s (быстрее проц не генерит) чем больше таблица дедупликации, тем больше операций записи на dedup устройстве по ощущениею скорость записи увеличивается, но не линейно, чем больше данных тем меньше ускорение роста скорости, но тем не менее оно неуклонно растёт на данный момент записано ~4,5ТБ данных (изначально пул пустой), скорость записи на dedup ~21МБ/сек (усреднненное за 15 секунд) оставлю генериться мусор до завтра, очень интересно какая будет скорость перезаписи в dedup устройстве когда будет хотя бы пару десятков терабайт.

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

пробовал и на голом диске - результат 1:1 кэширование на уровне vdev отключено в модуле - разработчики говорят что не эффективно

Ждал, когда же результаты от вас пойдут)) Как я и писал выше, 100Мбит/с нереально мало. Только будут ли данные дедупликацированные с /dev/urandom? Мне кажется, что нет

Нагрузку бы в нагрузке )))

Конечно нет этого и не должно быть. Цель протестировать нагрузку. Только я не пойму про какие 100мбит вы пишите

Я свой тестовый гоняю в рабочей нагрузке 🤷🏻‍♂️пока все нравится, но у меня файлы жирные

у меня постгре 300ТБ

пробовал и на голом диске - результат 1:1 кэширование на уровне vdev отключено в модуле - разработчики говорят что не эффективно

еще нажо попробовать fio запустить не на файле а на zvol, кстати изначально так надо было сделать. Давайте сразу с отключенными чексуммами. zfs creste -V 50G mypool/test.raw

момент

пробовал и на голом диске - результат 1:1 кэширование на уровне vdev отключено в модуле - разработчики говорят что не эффективно

пишем в блочное устройство - фс поверх не создавать?

Знаете где устпойство найти?

Конечно нет этого и не должно быть. Цель протестировать нагрузку. Только я не пойму про какие 100мбит вы пишите

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

Таблица дедупликации не пустая и растёт как на дрожжах

Есть изменения?

Но zfs в попугаях всегда утупала голому железу. Дело не в максимуме попугаев. Потрея попугаев не бесплатна. Как я писал выше, на реальной нагрузке zfs уменьшает iops сваливающиеся на устройства на порядок или больше. второй момент снимки, третий контрольные суммы, котопых нет в рейде. Если диск начал выдавать кривые данные, софтрейд поубивает всё, а зфс покажет проблему и продержится до замены диска, а если непродержится, то покажет в каких фацлах ошибки.

на пустом zvol сжатие не дает читать с устройства - получаются искусственно завышенные результаты

У меня массив nvme уступает на порядок...

да, точно. Zfs знает куда не писались данные. Надо его заполнить

Ждем патчей для nvme. Это не удивительно. У топовых nvme латентность сопоставима с озу. громоздкие механизмы очередей сильно тлрмозят все

Ждём, а пока я наблюдаю картину из разряда 12.1G на mdadm raid0 2-3G на страйпах zfs

сегодня смотрел - вроде коммитеры уже одобрили патч

уххх... бл...

это поверх ext4 поверх zvol read: IOPS=317, BW=5075KiB/s (5197kB/s)(297MiB/60017msec) латентнось 15 мс

Они одобрили его полгода назад

У меня массив nvme уступает на порядок...

но если делать в один поток - скорость случайного чтения из пула read: IOPS=176, BW=22.1MiB/s (23.2MB/s)(1327MiB/60001msec) clat (usec): min=21, max=35997, avg=5648.71, stdev=4481.83 lat (usec): min=21, max=35997, avg=5648.89, stdev=4481.83