Привет, @spirit! Спасибо за терпение. Давно хотел ответить, но всё было довольно напряжённо. По поводу кэширования, думаю, тут есть небольшое непонимание касательно выделения субкластеров и эффекта включения l2_extended=on. В QCOW включение l2_extended увеличивает накладные расходы на метаданные с 8 до 16 байт на кластер данных. Дополнительные 8 байт частично используются для битовой карты, которая отслеживает состояние выделения субкластеров. Само по себе это снижает эффективность кэша примерно на 50% из-за возросших накладных расходов на метаданные. QCOW-образы с выделением субкластеров позволяют разбивать родной кластер на 32 субкластера. Это не увеличивает размер адресного пространства (не создаёт дополнительную L3-таблицу). Вместо этого это даёт возможность загружать небольшие части кластера во время операции COW. Такая схема помогает оптимизировать производительность COW, особенно когда размеры I/O совпадают с размером выделения субкластеров. Чтобы сохранить одинаковую эффективность кэша при использовании субкластеров с l2_extended=on, нужно удвоить размер чанка, чтобы соотношение метаданных и данных оставалось постоянным. Чтобы действительно улучшить эффективность, размер чанка нужно увеличить ещё больше. По поводу практического вопроса, который мы обсуждали ранее: я провёл быстрый тест с диском 1 TiB и несколькими снапшотами на одной виртуалке. По грубым замерам (смотрел resident memory), удалось увеличить занимаемую QEMU память почти на 500 МБ, просто обращаясь к определённым сдвигам, совпадающим с L2-таблицей в каждом снапшоте. Это значит, что для увеличения кэша не нужно касаться всех данных, достаточно нескольких стратегических сдвигов. Учитывая современную производительность систем, сделать это можно всего за пару сотен микросекунд. Что касается оптимизированного обнуления — добавлю это в список того, с чем хочу поэкспериментировать! Blockbridge: ультранизкая задержка, полностью NVME-шаред-сторедж для Proxmox — https://www.blockbridge.com/proxmox

Привет, @spirit! Отличная работа! Могу подтвердить, что обнуление блоков работает отлично. Мы видим примерно 8 ГБ/с при безопасном извлечении — это довольно неплохо. Одно что бросилось в глаза: похоже, что для обнуления не используется O_DIRECT? Есть ли риск, что обнулённые блоки могут остаться в буфере и не попасть на диск при отключении питания? Blockbridge: сверхнизкая задержка, полностью NVME-общее хранилище для Proxmox — https://www.blockbridge.com/proxmox