А такой объём не обязательно, так как SSD можно использовать для ZIL

Вопрос. Пробовал на 20.04 (5.4) и на 22.04 (5.15). Кстати ZoL очень хорошо переживает мажорное обновление Есть диск NVMe (форматирован в 512б), который при randwrite direct=1, buf=0, inval=1, bs=8k, iodepth=32, выдаёт 1600 MiB/s Когда на него делается strip zpool: zpool create -o ashift=9 -O compression=lz4 -O atime=off -O recordsize=64k nvme /dev/nvme0n1 Я получаю 147MiB Когда делаю: zpool create -o ashift=9 -O compression=lz4 -O atime=off -O recordsize=8k nvme /dev/nvme0n1 Получаю: 349 MiB/s what the hell? Судя по гуглу - с этим кто-то сталкиваться, но ответы идут из разряда - у вас диск гавно

Зил то причём тут

У кого-то есть идеи на тему этого? Дополнительно собираю mdadm в страйп (3 диска) получаю 5.6к миб/с (на блоках fio 64к), собираю zfs stripe на volblock=8к при блоках fio 64к - получаю 1100 миб/с

Какая ФС и как тюнингована на zvol?

У кого-то есть идеи на тему этого? Дополнительно собираю mdadm в страйп (3 диска) получаю 5.6к миб/с (на блоках fio 64к), собираю zfs stripe на volblock=8к при блоках fio 64к - получаю 1100 миб/с

Потому, что это кеш на запись.

Это ни разу ни кэш на запись

Смысла в 512 форматировать нвме вроде как давно уже нет. Коллеги, поправьте, если ошибаюсь.

Первый абзац

Это не кеш, а быстрая фиксация транзакции

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

Айноды это в другой абстракции.

Сначала запись происходит в журнал транзакций, а потом уже в пул. Если ZiL вынести на отдельное устройство, то по смыслу он кэш

Возвращаюсь: как это устроисвто помогает ворочать медиа файлы ?🤔

Возвращаюсь: как это устроисвто помогает ворочать медиа файлы ?🤔

Почти никак. Но зависит от нагрузки. Если много небольших записей - ускорит отзывчивость. Пример - БД. А на запись линейно больших файлов смысла особо нет

Оно поможет если Ваше ПО постоянно куда-то записывает мелкие метки на диски, вместо того, чтобы просто читать с них. Если Ваше ПО целиком выгружает файл в оперативу, а потом сохраняет каждые 5 минут на диск - то никак

Оно поможет если Ваше ПО постоянно куда-то записывает мелкие метки на диски, вместо того, чтобы просто читать с них. Если Ваше ПО целиком выгружает файл в оперативу, а потом сохраняет каждые 5 минут на диск - то никак

Сейчас - zpool create -o ashift=12 -O compression=lz4 -O atime=off -O recordsize=8k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme3n1

Можно нагрузку раскидывать по разным датасетам или зволам, смотря что у вас там

Начать с 64 или 128, а там посмотреть

Зависит от количества потоков

Смысла в 512 форматировать нвме вроде как давно уже нет. Коллеги, поправьте, если ошибаюсь.

недавно читал что какая-то модель на 512 оказалась быстрее. хотя это исключение из правил.

Зфс это не про производительность в однопотоке

Зфс это не про производительность в однопотоке

numjobs=32 и numjobs=4 показывают одинаковую производительность для recordsize=8к с блоком fio 64к ~400 миб/с

Так как смысла в целом в этом тесте нет

Нфс кстати пишет не кусками по 4-8

Поэтому я и делал изначально recordsize=8k. учитывая, что я планирую выдавать это в vmware - Винда, линукс, Cisco и кучка БД конечно не особо будут рады, когда им скажут, что в 4к писать низя

Бд скорее всего в 32кб будет писать

Немного зил сюда, и будет оптимально

Windows с ntfs с дефолтным 4к и linux с ext4 и дефолтным 4к и mysql с дефолтным 16к - конечно их всех можно тюнить

zil для nvme?

А, да. Не надо

Если сервисы ЗФС стоят этих 50 процентов, то ставь ее

Цена надёжности и консистентности

Она просто работает иначе :) Если рейд0, то в зфс смысла вообще нет

Цена надёжности и консистентности

То есть на Ваш взгляд это нормально?

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

Необязательно, это всего лишь потребители