Comments 36
Вам стоит поработать над графиками и представлением данных, потому что и в первой и во второй статье всё с ними печально.
Например, у вас ни на одном графике не подписана вертикальная ось, и что именно там за попугаи и какое направление (меньше или больше) лучше — не понятно.
Можно было бы сопоставить с данными из таблиц, но таблицы у вас разбросаны по статье и сгруппированы отличным от графиков образом:
в графике к вас идут ФС сгруппированые по тестам, а в таблицах тесты сгруппированые по ФС.
Последовательность изложения тоже довольно непонятная, т.к. нет оглавления или нумерации вложенности (1, 1.2, 1.2.3 и пр.) нет, то очень просто запутаться где заканчивается секция, и начинается подсекция.
В целом конечно данные есть, и из них можно сделать выводы, но статью читать очень сложно, поэтому для этого нужно постараться. Но если вам, как писателю, нужно постараться один раз, то каждый читатель это будет делать снова и снова отдельно.
Спасибо за Ваш комментарий, доработал с точки зрения оформления.
Графики сгруппированы двумя образами, первый по используемому рейду (где заголовок это протокол подключения, а содержимое графика это рейды) и по используемому протоколу (где заголовок это рейд, а содержимое графика это протоколы подключения)
На локальной системе у вас получилось, что mdadm'овый рейд быстрее LVM на паттернах последовательной записи и, особенно, однопоточного случайного чтения. А через сеть получается, что LVM строго быстрее. Почему так может быть?
И еще за методологию хочется спросить. Вы делали одни и те же тесты несколько раз, а потом усредняли? Или просто один раз тест проводили и записывали результаты?
Вот да поддержу про методологию. Что по sysctl на Ubuntu, как минимум vm.dirty_bytes, vm.dirty_background_bytes, vm.dirty_expire_centisecs и vm.dirty_writeback_centisecs? Стандартные хорошо работают если памяти всего 1-2 гига, и плохо, если больше.
Спасибо, буду знать про них
Бесполезный и бессмысленный совет в лучшеих традициях краго-культа.
Эти параметры относятся к VFS и page cache, а при тестировании дисков fio принято запускать с флагом direct=1, что приводит к тмоу, что вы можете в эти параметры хоть что записать, потому что значения не используются.
P.S.: ZFS это вообще отдельная песня, но на нее эти параметры тоже не действуют (по другим причинам, но те мне менее)
https://github.com/openzfs/zfs/issues/11407
это какой-то другой zfs, или там в обсуждении идиоты одни обсуждают уменьшение dirty bytes кеша и его положительный эффект?
Там альтернативно талантливые люди героически создают себе проблемы и потом их потужно перемогают.
Суть их проблемы в том, что они создали ZVOL, создали на нем файловую систему и смонтировали ее (в /blobs, но это не имеет значения - достаточно того что они создали ФС поверх блочного устройства ZVOL). В результате у них создалось два кэша - один page cache над ZVOL и второй внутри ZFS ее собственными средствами. После чего они ломанулись героически решать указанную проблему.
В случае же этой статьи (и c учетом предыдущей) ясно, что авторы также используют ZVOL, но в отличие от людей по ссылке, они, действуя вполне разумно, подают его в ядерный таргет линукса, а в нем ZVOL подключется как /backstore/blockio (при попытке засунуть блочное устройство в /backstores/fileio targetcli ругается). По умолчанию, writeback кэш там не используется (да и writethrough тоже0 и устройство открывается как раз в режиме direct I/O.
Поэтому да, повторю - параметры тюнинга VFS и кэшей здесь не используются и результата не дадут.
Если обратиться к первой статье, то LVM был в среднем на 6% быстрее чем mdadm. Тут же наблюдается схожая картина.
К тому же прошу не забывать, что тесты не являются аналогичными.
Я похожие показатели на 4K random получал с дисковой полки через стандартный 25G iSCSI без всяких NVMe и оффлоадов на виндовом хосте с бэкенда на SAS накопителях, и не на RAID-0, а на вариации RAID-6. Что-то у вас явно не так, особенно в случае с ZFS, которая часто используется в качестве бэкэнда в современных хранилищах и такого ужаса, конечно же, там не показывает.
Коллега, прошу тогда тесты в студию. Если у Вас массив на 6 дисков в 6-м показывал схожие результаты на двух хостах, то я бы с удовольствием увидел Ваш стенд и методику тестирования.
Тот массив давно уже в работе, а лишнего железа у меня сейчас нет. Но из того, что я вижу у вас - ПСП-то сетевух вы померяли, но на рэндом тестах важна не она, а латентность, и основное влияние NVMe-of в теории именно на нее должно быть (собственно в ней и есть основной провал между DAS и SAN на SSD). Не хотите посмотреть на неё, и на чисто сетевую, и на подключенные по сети диски?
А про ZFS ничего не могу сказать, тут я чисто на сторонние данные ориентируюсь.
Боюсь тогда я не совсем понимаю, какие именно параметры Вы сравниваете.
Вы даже не описали:
сколько у Вас портов iSCSI
есть ли коммутатор
с помощью чего Вы давали нагрузку
какие у Вас сервера
сколько серверов
сколько дисков было
какого они (диски) объёма
какой сторадж у Вас был для объединения
Задача "как получить 150К иопс с нескольких NVМe дисков" мне не видится настолько интересной, чтобы всерьез тратить время на углубление в детали. Я просто отметил, что схожая производительность по iSCSI в принципе нормальна для AFA хранилищ без всякого NVMe.
Основной смысл NVMe-of, как я уже писал, в снижении времени отклика, которое в случае стандартного iSCSI совершенно несопоставимо с DAS на флэше. Вы же время отклика, как я понимаю, вообще не меряли, поэтому тесты на random io у вас по сути неполноценны.
Коллега. Вы говорите, что такую же производительность видели и на системе с 25Г iSCSI, не уточняя, что это была за система и сколько она стоила. Если у Вас были абсолютно аналогичные тесты в таких же условиях, то это другая ситуация.
Но говоря, что поделка на 6 дисков за ~160к (сервер+диски) показывает такие же результаты как массив стоимостью в 500к+ рублей - спасибо, приятно знать.
Я вам про Фому, вы про Ерему. Еще раз - проведите замеры латентности, сравните со стандартным iSCSI, и вот там будет видно, дает ли какой-то профит NVMe-oF в вашем конфиге (сейчас этого не видно) или же вы настройки сделали, а особого результата они не дали.
Я не совсем понимаю причём тут iSCSI в целом, так как я вообще не сравниваю ничего из этого с iSCSI. Вся статья идёт вокруг соединений с использованием RDMA.
Еще раз. По результатам вашей статьи пока не складывается впечатления, что задействование iSER и NVMe-oF у вас дало результаты, для которых эти технологии в принципе были созданы (а именно, борьба с проблемой многократно более высокого времени отклика SAN по сравнению с DAS на SSD).
То есть вы вот что-то сделали - и оно как-то заработало. Ну ок, а насколько хорошо? Или вы априори так твердо уверены, что выжали максимум из доступных технологий?
Я априори уверен, что использовать iSCSI будет медленнее. Можно ли получить такие же цифры с ним в других условиях на других серверах с другим количеством дисков на enterprise массиве? Да, можно. За х10 стоимости.
Касаемо выжать всё - для этого мне нужны 2x100Г сетевые карты x16 pcie 4.0 (~252 Гбит/с), а не 2x40Г x8 pcie 3.0 (~63 Гбит/с).
Тест iSCSI vs iSER vs NVMe-oF не совсем планировался, так как их много и без этого.
Время отклика доступно в архивах, так как HCIbench также замеряет его.
Причина почему я не стал его выводить на графики в том, что latency&глубина очереди&скорость&iops все являются связанными параметрами. Нельзя иметь выше iops и выше задержку при неизменной глубине очереди. Или выше скорось, при более высокой задержке при равной глубине очереди. Если это не так прошу меня просвятить
Хорошо, последняя попытка. NVMe-over-Fabrics_Performance_Characterization.pdf (systor.org) - смотрите на разницу DAS/NVMe-oF, сравните с вашим случаем. Ни на какие мысли не наводит?
Вы сейчас не туда воюете. Или я не понимаю куда.
Вы буквально отправляете мне статью, где речь идёт по:
`ConnectX-4 100Gb Ethernet NICs with RoCE support`
О чём я говорил ответом выше.
Ещё раз повторюсь, тут не стоит речь выжимать из технологий 100%. Это сборка на коленках из подручных средств.
Вы же говорите про лабораторные массивы, AFA enterprise массивы и прочие Enterprise вещи. Тут даже близко такого нет. Это процы и материнска с алика, диски с авито и бесплатный SPDK запущенный по документации вендора. С тем же успехом можно говорить, что SPDK не оптимален и не использует мультипоток.
P.S. iSER и NVMe-oF в 100% лучше iSCSI при прочих равных.
Я разными способами пытаюсь вам объяснить, что ваши результаты демонстрируют только одно - у вас что-то работает неправильно, и ваша система, несмотря на ваши заявления о поиске "максимальной" производительности (даже raid-0 для этой цели сделали), на деле не подбирается к ней даже близко ни по каким параметрам, кроме разве что линейных операций, причем ни в каком рассматриваемом случае (ибо в случае с ZFS очевидна неадекватная работа ещё и её).
Вы всерьез думаете, что по ссылке какие-то специальные "лабораторные" зионы или мелланоксы? Или что ПСП 100G карты сыграет какую-то роль на случайном доступе, который у вас даже 10G не утилизирует, а тем более для случая QD1? Или вы полагаете, что именно разница в доли микросекунды отклика между 40G и 100G приводит в вашем случае к падению iops на порядок? Или все-таки дело в том, что по ссылке всё настроено и работает правильно и демонстрирует производительность, заявленную в спецификациях, а у вас - нет? Спецификаций вам мало, результатов чужих тестов - мало, так что вам вообще надо, чтобы вы поверили, что с вашими тестами что-то не так? :)
у вас что-то работает неправильно
Вы так и не объяснили почему это так. В первом посте Вы привели в пример непонятный iSCSI enterprise массив на 25Г. Без ЛЮБОГО описания стенда и тестов. На вопросы что за стенд Вы не отвечаете.
к ней даже близко ни по каким параметрам
Ради всего святого. Как раз тут я подбираюсь к эффективно пределу интерфейсу 3.0 x8, если запустить 1М 100% read\write, то я как раз и попаду в этот лимит.
100G карты сыграет какую-то роль на случайном доступе
....на этой шикарной фразе у меня закончились силы объяснять.
Буду рад увидеть Вашу статью про это с Вашим Enterprise массивом или про то как правильно настроить стенд NVMe-oF с SPDK для VMware. Все настройки, что я делал приведены в статье. Свыше этого не менялось ровным счётом ничего и нигде.
Без ЛЮБОГО описания стенда и тестов. На вопросы что за стенд Вы не отвечаете.
Есть такое понятие - "типичные показатели". Для примера, типичный показатель iops для случайного чтения с 7200К HDD составляет порядка 200, +- проценты. И при правильной работе системы и правильном измерении это мало зависит от конкретной модели (и принадлежности или нет ее к энтерпрайз классу), конкретной конфигурации стенда, используемого для измерения ПО, и т.п., а обусловлено лишь физическими возможностями технологии. Если кто-то намерял 180 или 250 - это вполне может быть ок. Но если кто-то намерял 20 иопс - это показатель недостоверности тестирования или проблем в работе. Если кто-то намерял 2000 - это показатель недостоверности тестирования.
Так вот в вашем случае я говорю именно о таких типичных показателях. Ваши цифры типичны для iSCSI и местами в разы, местами более чем на порядок ниже тех, что должны быть при правильной работе NMVe-oF. Где конкретно в цепочке лично у вас завелись лишние потери - это вопрос. Если вам неинтересно с этим разбираться - ну ок. :) Тогда тем более это неинтересно мне. Это же ваш стенд, а не мой, достичь "максимальной" производительности хотите вы, а не я, так чья должна быть инициатива в поиске узкого места? А сейчас я просто вижу конечный результат, он экстремально низкий для заявленной технологии. О чем я и предупреждаю уже даже не столько вас, сколько ваших читателей.
Ради всего святого.
Ради хоть какого-нибудь святого, перестаньте уже в каждом сообщении путать пропускную способность интерфейсов и их время отклика, они НЕ связаны напрямую.
Для того, чтоб использовать ZFS - надо изучить КАК оно работает и дальше думать своей головой, а не гуглом и хау-ту. Ужас в том, что нужно отталкиваться от применения, а не пытаться играть в синтетику на настройках по-умолчанию (хорошо хоть не 1М recordsize выставили). Сжатие - используют, чтоб "влезло побольше" (например, библиотека стим :) ), или "прочиталось чуть быстрее с медленных накопителей" (hdd 2.5" sata 7200), возможно - "съёкономить ресурс флэша" (очень спорный случай - перезапись мелких блоков приведёт к перезаписи громадного куска данных). Но никак не для "поднять производительность".
А уж дедупликация - это не о производительности совсем. Это о её катастрофе :).
Про сжатия - уже было проверено (и не только мной), что оно не даёт негативных показателей для скорости.
По дедуп - это больше для справки, на случай, если его захотят включить при использовании NVMe носителей.
Хотелось бы добавить, что zfs в простейшей конфигурации: несколько vdev без special (для метаданных), slog (для ускорения синхронной записи), dedup (для ускорения дедупликации) и cache - без этого всего, zfs скорее способ получить высокую надежность хранения данных при удовлетворительном быстродействии. Используя же все механизмы заложенные в этот комбайн вы можете построить по настоящему хорошо адаптированное для нагрузки решение.
Кроме того, меня расстраивают попытки сравнивать производительность zfs с чем-то простым типа lvm. Вот вам пример: 8 SAS дисков 15KRPM собранные в конфигурацию RAID10+LVM, которая просто в щи уделывает zfs на тех же дисках в синтетических тестах, еле-еле вывозили нагрузку от пары десятков виртуалок с базами данных. Важно отметить, что использовались снимки LVM. Когда эту связку заменили на zfs версии 0.6 (это самые первые версии zfsonlinux), нагрузка на диски упала до 6%, в то время как мы получили возможность делать не один снимок, после которого 40% утилизация дисков возрастала до 80%, а несколько сотен снимков, без роста нагрузки на диски + получили возможность инкрементальной асинхронной репликации.
И то же самое можно сказать почти про каждый аспект технологии zfs. Например, на приведенных ТС графиках, видно, что zfs уступает, не менее чем в 2 раза в лучшем случае по iops. Так это не удивительно, там же управление транзакциями добавляет как раз +100% iops минимум. Подключите special vdev и эта дополнительная нагрузка перейдёт на него. Это особенно полезно в комбинированных пулах на НЖМД, где метаданные вынесены на твердотельные накопители.
Ещё пример, дедупликация. Практика показывает, что удовлетворительное быстродействие можно получить подключив dedup vdev на nvme intel optane. Каждый optane vdev даст примерно 1Гбит скорости дедупликации (это очень грубо), если для dedup будет использоваться что-то типа SATA intel s3710, то можно рассчитывать примерно на 100 мегабит скорости дедупликации (тоже очень грубо).
Как выглядит подходящее использование zfs? У вас огромный пул из нескольких десятков или сотен НЖМД, объединенных, например в множество vdev raid-z2 объемом от 100ТБ до единиц ПБ, данные хранятся с подходящим сжатием, это дает x2..x3 к вашим условным 100ТБ, горячие данные кэшированы на твердотельных накопителях, это дает высокую скорость чтения, у вас есть slog для ускорения синхронной записи, а асинхронная и так достаточно быстра, т.к. zfs использует writeback. Вы не переживаете из-за потери данных при сбое питания, т.к. данные всегда записывают консистентно, а там где это требуется, приложения используют синхронную запись, которая не будет потеряна при сбое питания. Кроме того у вас нужное количество dedup vdev, по этому ваши виртуальные 300ТБ могут увеличиться ещё в несколько раз. По этому, в вашей системе может хранится около 1ПБ данных на хранилище НЖМД объемом в ~100ТБ и если вы всё учли, то это будет работать с удовлетворительной скоростью. И над всем этим великолепием ещё и создаются консистентные снимки, содержимое которых инкрементально передается на другую такую-же систему в соседнем ЦОД. Наверное единственное слабое место этой системы будет в латентности - вот что имеет смысл измерять. Я ещё забыл тут написать про шифрование.
Можно ли построить что-то подобное на других технологиях и не потерять данные? На mdadm + LVM - точно нет. Вы, неизбежно потеряете данные рано или поздно, т.к. нет контрольных сумм и нет транзакционной записи. Причем о потери данных, вы возможно, не узнаете, пока не станет слишком поздно. Я имею в виду, что mdadm как и аппаратные raid-массивы не имеют возможности отличить корректные данные возвращаемые накопителем от данных с ошибками.
zfs - это карьерный самосвал в мире файловых систем. Глупо сравнивать его только по скорости даже с картингом (lvm). Когда говорят, что zfs - быстраф FS, имеется в виду, что вы сможете повесить на неё большую полезную нагрузку, чем на другие варианты организации тех же накопителей при разумном подходе. На деле так и происходит, но этого, к сожалению, не могут выявить синтетические тесты. Наверное, более правильным вариантом тестирования zfs было бы записать профиль некой эталонной нагрузки и попробовать воспроизводить его параллельно увеличивая количество потоков до тех пор пока не будут достигнуты предельные показатели по латентности.
Коллега. Я не сравнивал функциональность. Я даже отдельно обговорил это в самом начале при постановке смысла статьи.
"Смысл данной статьи остаётся схожей, показать максимальную производительность, когда вопрос сохранности данных решается репликами или бэкапами."
Данные хоть в кашу могут превращаться (рейд 0 намекает на это), вопрос что покажет максимальную производительность из решений, что на слуху и используются.
А именно - mdadm, LVM и ZFS. Когда bcachefs будет принята в ядро Linux и появятся руководства по его использованию - оно тоже будет дополнено в статью.
Вы же описываете мне типичный ответ человека, который защищает ZFS -
`ZFS куда лучше справляется с сохранностью данных жертвуя производительностью.`
`ZFS имеет фичу А,Б,В,Г,Д, а mdadm\LVM не позволяют это.`
`ZFS позволяет себя оптимизировать под разные задачи.
Я ни разу не спорил с этим и не планирую. Аналогично про HDD. Я ни разу не спорил, что mdadm или lvm лучше справляются с работой с сотнями HDD. Нет. Речь строго про NVMe и производительность (скорость работы). Кто-то посмотрит, что ZFS теряет только 60% производительности и его это устроит. Кто-то скажет, что это слишком много и будет ждать O_DIRECT патча для NVMe в ZFS 3.0. Но ни разу целью статьи не было сравнивать сохранность данных или функциональность.
Единственный раз, когда я упоминал функциональность это дополнительный 4-й вариант -ZFS+dedup. Который как раз и отмечен, как самое функциональное решение. Но это не более чем как тест в ZFS на 64 потока в части 1. Дополнительный не особо интересный тест
Теперь больше конкретных ответов на Ваши слова:
Подключите special vdev
dedup vdev
У меня буквально уже PCIe 4.0 диски. Вы бы ещё l2arc предложили подключить.
И над всем этим великолепием ещё и создаются консистентные снимки, содержимое которых инкрементально передается на другую такую-же систему в соседнем ЦОД
Про функцинальность я ответил выше
не потерять данные
о потери данных
Ответил выше, в первом абзаце статьи
Я видимо плохо донес мысль. Меня расстраивают такие тесты, т.к. вместо пользы они дают ложное представление, уводя внимание специалиста на показатели, численные значения которых не будут соответствовать полезности результата.
Попробую пояснить по другому. Подход zfs основан на ускорении за счет транзакций и writeback-буферизации. Вы, либо вынуждены были обойти или отключить механизм writeback и получить заведомо меньшее быстродействие, либо получили бы заведомо больше быстродействие, грубо говоря, почти как у RAM-диска. Оба эти результата бессмысленны.
Далее, мои замечания могут вам показаться мелкими придирками, но я настаиваю, что они важнее чем кажутся. По видимому, вы не обратили внимание на утверждение, что данные сохранить другими путями, не возможно в принципе.
> Данные хоть в кашу могут превращаться (рейд 0 намекает на это), вопрос что покажет максимальную производительность из решений, что на слуху и используются.
Вопрос в том, что указанные вами средства не защитят вас от порчи данных, если вы об этой порче вовремя не узнаете. А узнаете вы когда у вас что-то упадёт. А может не падать, а давать не верный результат, например. Эти не верные данные, которые могут выдаваться глючащими nvme-дисками и часто выдаются изношенными НЖМД, будут переданные в реплики и бекапы, и таким образом размер катастрофы станет только больше. Даже на RAID0 вам будут полезны контрольные суммы, чтобы узнать что данные ещё живы и точны или пора восстановиться с бекапа.
Возвращаясь к вашему утверждению про "Данные хоть в кашу могут превращаться". Тогда вам нужно было отключить контрольные суммы. Если данные совсем не важны, то и синхронную запись надо было отключить тоже. И Вы бы получили результат в разы отличающейся в большую сторону. Ваш результат не максимальный.
> У меня буквально уже PCIe 4.0 диски. Вы бы ещё l2arc предложили подключить.
А вы попробуйте подключить special и результаты опять изменятся в большую сторону. Замеренная вами производительность, опять же не максимальная.
Так вас интересует максимальная производительность или не интересует?
Но самым важным было то, что ваши тесты не дают полезной информации. Если бы в тестах не было zfs можно было бы эти попугаи сравнивать напрямую, т.к. быстродействие остальных систем на самом деле примерно пропорционально замеренным iops. Но раз уж вы добавили zfs, то надо было создать профиль нагрузки, выбрать приемлемую латентность, и нагружать систему все увеличивающимся количеством параллельно работающих клиентов, до тех пор пока не будет достигнут предел по латентности. Но такое исследование имеет смысл применять к конкретному виду заранее известной нагрузке.
Как раз мысль донесена корректно. Вы в тесты на производительность NVMe, где полезный смысл лежит в скорости работы пытаетесь принести "Почему многофункциональный ZFS используется для HDD?". Статья никак не связана с этим.
вас от порчи данных,
Я на всякий случай ещё раз продублирую.
вопрос сохранности данных решается репликами или бэкапами
Умерла ВМ от того, что у неё отмер блок данных в силу Silent Corruption из-за разряда ячейки? Восстановили из бэкапа\работающей реплики.
Подход zfs основан на ускорении за счет транзакций и writeback-буферизации.
Коллега, мне не нужно описывать процесс работы ZFS. Я также читал статью по ZFS, на которую ссылался в первой статье.
Тогда вам нужно было отключить контрольные суммы
Дефолтные опции. Но я посмотрю, есть ли разница в тестах при их отключении, спасибо.
подключить special
Эх, давайте не будем продолжать это. Я бы с удовольствием ткнул в документацию, которая рассказывает про special, а потом в тот, факт что он нужен, когда сам массив работает медленее, чем Special, а у меня ситуация как раз не такая. Но не стану.
ваши тесты не дают полезной информации
Они дают цифры производительности для определённых тестов с определённой нагрузкой в одинаковых условиях. That's it. Не больше, не меньше. Показывают ли они что ZFS `многофункциональная система, которая своимми фичами может покрыть тот факт, что она невероятно медленее работает с NVMe, чем LVM\MDADM` - каждый решит сам для себя.
"zpool create -o ashift=12 -O compression=lz4 -O atime=off -O recordsize=128k" и далее читают кусками по 4К. По части ZFS - cтатья о "Сдуру можно и ... сломать".
Для того, чтоб прочитать ваши 4К - нужно прочитать то количество блоков, во что сжали 128К, разжать, выдать ваши 4К из 128К - оверхед огромный по всем частям процесса. Если нужно читать рандом 4К и иметь профит от сжатия - нужно балансировать с размером блока и recordsize. Иногда, наплевав на "рекомендации", делать blocksize 2К при физических 4, и recordsize 8-16K. Чтение невыровненных по recordsize данных - тоже весело, 2х нужно прочитать-распаковать.
Короче, ZFS - это не серебрянная пуля, а решение требующее понимания с какими данными и как будут работать.
Ну и полу-холиварный срач по поводу "а шото у меня фря 13 веселее убунты 22 в рандоме работала" (создаём ФС - ext4 на zfs volume, заливаем пачку исходников, один и тот же пул отдаём из фри и линукса, читаем их tar ) - разводить не буду, т.к. настраивать zfs в линуксе - "не начинал".
Да, как я упоминал - используются настройки по-умолчанию. Также отмечу, что стоит обратить внимание, что я использовал zvol, который читает блоками по 8к (раньше по 4к).
В данной статье нет цели максимально оптимизировать mdadm\lvm\ZFS под конкретные тесты\среду\нагрузку - все настройки являются по-умолчанию. Кроме сжатия для ZFS, но насколько мне известно, доказано многочисленными тестами, что lz4 не оказывается влияния на производительность zvol. Если у Вас есть другая информация - я буду рад её узнать
Про чтение кусками по 4к, 8к, 64к - к сожалению, я не знаком с настройками, которые запретят ОС в виртуализации читать свои данные по 4к, когда они хотят считать 4к.
> lz4 не оказывается влияния на производительность zvol
Я бы сказал, что на указанные тесты в случае с zfs на быстрых nvme сильно повлияет частота процессора. А для синтетической нагрузки, любое сжатие может сильно повлиять на результат, в то время как на реальной нагрузке, влияние может быть противоположным.
Кажется не очень корректно сравнивать ZFS с compression=lz4
Производительность блочного хранилища на основе софт рейдов (mdadm, LVM и ZFS) при использовании iSER и NVMe-oF