Настройка параметра кэша L2 для Qcow кажется очень важной для просто "нормальных" размеров дисков Qcow... Вот хорошее объяснение этой проблемы, которое я скопировал с blogs.igalia.com/berto/2015/12/17/improving-disk-io-performance-in-qemu-2-5-with-the-qcow2-l2-cache/. Файл qcow2 организован в единицы постоянного размера, называемые кластерами. Виртуальный диск, видимый гостем, также разделен на гостиные кластеры того же размера. QEMU по умолчанию использует кластеры по 64КБ, но при создании нового образа можно указать другое значение: qemu-img create -f qcow2 -o cluster_size=128K hd.qcow2 4G. Чтобы сопоставить виртуальный диск, видимый гостем, с образом qcow2 на хосте, образ qcow2 содержит набор таблиц, организованных в двухуровневую структуру. Эти таблицы называются L1 и L2. Для каждого образа диска существует одна единственная таблица L1. Эта таблица небольшая и всегда хранится в памяти. Может быть много таблиц L2, в зависимости от объема выделенного пространства в образе. Каждая таблица имеет размер одного кластера. Для того чтобы прочитать или записать данные на виртуальный диск, QEMU нужно прочитать соответствующую таблицу L2, чтобы узнать, где находятся эти данные. Поскольку чтение таблицы для каждой операции ввода-вывода может быть дорогостоящим, QEMU хранит кэш таблиц L2 в памяти, чтобы ускорить доступ к диску. Кэш L2 может значительно повлиять на производительность. Например, вот количество операций ввода-вывода в секунду, которое я получаю при случайных запросах чтения в полностью заполненном дисковом образе объемом 20ГБ: РАЗМЕР КЭША L2 СРЕДНЕЕ           IOPS 1 МБ                                                5100 1,5 МБ                                              7300 2 МБ                                               12700 2,5 МБ                                            63600 Чтобы выбрать размер кэша, нам нужно знать, как он соотносится с объемом выделенного пространства. Объем виртуального диска, который может быть сопоставлен кэшем L2 (в байтах): disk_size = l2_cache_size * cluster_size / 8. При значениях по умолчанию для cluster_size (64КБ) это disk_size = l2_cache_size * 8192. Таким образом, чтобы иметь кэш, который сможет покрыть n ГБ дискового пространства при размере кластера по умолчанию, нам нужно l2_cache_size = disk_size_GB * 131072. У QEMU есть кэш L2 по умолчанию размером 1МБ (1048576 байтов), поэтому, используя формулы, которые мы только что видели, мы имеем 1048576 / 131072 = 8 ГБ виртуального диска, покрытого этим кэшем. Это означает, что если размер вашего виртуального диска больше 8 ГБ, вы можете ускорить доступ к диску, увеличив размер кэша L2. В противном случае вы можете оставаться с настройками по умолчанию. Как настроить размер кэша Размеры кэша можно настраивать с помощью опции -drive в командной строке или команды 'blockdev-add' QMP. Доступно три параметра, и все они принимают значения в байтах: l2-cache-size: максимальный размер кэша таблицы L2 refcount-cache-size: максимальный размер кэша блока refcount cache-size: максимальный размер обоих кэшей вместе. Есть два момента, которые нужно учесть: как кэш L2, так и кэш блоков refcount должны иметь размер, кратный размеру кластера. Если вы установите только один из вышеперечисленных параметров, QEMU автоматически подгонит остальные так, чтобы кэш L2 был в 4 раза больше, чем кэш refcount. Это означает, что эти три варианта эквивалентны: -drive file=hd.qcow2,l2-cache-size=2097152 -drive file=hd.qcow2,refcount-cache-size=524288 -drive file=hd.qcow2,cache-size=2621440. Хотя я не рассматриваю кэш refcount здесь, стоит отметить, что он используется гораздо реже, чем кэш L2, поэтому вполне разумно оставить его небольшим: -drive file=hd.qcow2,l2-cache-size=4194304,refcount-cache-size=262144. Проблема с большим размером кэша заключается в том, что, очевидно, он требует больше памяти. У QEMU есть отдельный кэш L2 для каждого файла qcow2, поэтому если вы используете много больших образов, вам может понадобиться значительное количество памяти, если вы хотите иметь разумный размер кэша для каждого из них. Проблема ухудшается, если вы добавляете файлы обратной связи и снимки. Управление этими параметрами может дать значительный прирост производительности для некоторых случаев использования, и возможность редактировать их в панели создания дисков Qcow в Proxmox могла бы стать большим улучшением

Говоря о будущем улучшении Proxmox VE в отношении Qcow2, есть еще одна важная переменная, которую стоит взять под контроль — это размер кластера Qcow2. Хорошее объяснение важности размера кластера Qcow2 можно найти в блоге jamescoyle "2055-qcow2-image-format-and-cluster_size": "Виртуальный диск, подобно тому, как операционные системы обращаются с физическими дисками, разбивается на кластеры; каждый кластер имеет предопределенный размер и содержит единицу данных. Кластер — это минимальное количество данных, которое можно прочитать или записать за одну операцию. Существует индекс, который часто хранится в памяти и знает, какая информация хранится в каждом кластере и где расположен этот кластер. Файловая система qcow2 работает по принципу copy-on-write (q’cow’2), что означает, что если блок данных нужно изменить, то весь блок перезаписывается, а не только измененные данные. Это значит, что если у вас размер блока 1024 (байта) и вы изменяете 1 байт, то 1023 байта должны быть прочитаны из оригинального блока, а затем 1024 байта должны быть записаны — это накладные расходы в 1023 байта, которые нужны для чтения и записи помимо изменения в 1 байт. Эти накладные расходы не кажутся серьезными в большом масштабе, но представьте, что у вас размер блока 1 МБ и вы изменяете всего 1 байт! С другой стороны, при больших записях возникает еще одна проблема. Если вы постоянно записываете файлы размером 1 МБ и размер блока равен 1024 байтам, вам придется разбить этот 1 МБ файл на 1024 части и хранить каждую часть в кластере. Каждый раз, когда кластер записывается, метаданные должны обновляться, чтобы отразить новые данные. Опять же, это приводит к снижению производительности при хранении данных таким образом. Более эффективный способ записи файлов размером 1 МБ — использовать размер кластера 1 МБ, чтобы каждый файл занимал один блок с только одной ссылкой на метаданные." Это известно как "Усиление записи" в файловой системе гостя на Qcow2. Чтобы минимизировать усиление записи, размер сектора гостя нужно "настроить" для конкретного случая использования. Чтобы минимизировать усиление записи в виртуальных средах, размер сектора гостя необходимо "настроить". НО вам также нужно учитывать усиление записи, которое вы можете испытывать из-за несоответствия размера кластера Qcow2 и базовой файловой системы Posix, на которой находится файл Qcow2. Например, когда вы используете файл Qcow2 на хранилище, предоставляемом через NFS на ZFS-системе, вы используете размер кластера 64K поверх (возможно) 128K наборов записей (это стандартный набор записей ZFS). Qemu позволяет установить размер кластера Qcow от 512 байт до 2 МБ. Конечно, вы можете действовать на набор записей ZFS, чтобы привести его в соответствие с размером кластера Qcow 64K, но иногда может быть полезно иметь возможность управлять параметром размера кластера Qcow2 также в панели создания диска VM в Proxmox для настройки конкретных случаев использования. Поэтому необходимо позаботиться о улучшении панели создания Qcow2 и учесть уровень L2 кеша и размер кластера. Обратите внимание, что при использовании большего размера кластера вам нужен меньший размер L2 кеша для того же размера диска, так как количество записей в L2 таблице меньше. На самом деле размеры диска Qcow2, размер кластера Qcow2 и размер кеша L2 таблицы Qcow2 могут быть "связаны" для достижения наилучшего результата, поэтому панель Proxmox могла бы "автоматически" устанавливать правильные значения, но позволять людям свободно изменять цифры для специфичной настройки.