Я хочу построить небольшой домашний сервер виртуализации на базе ProxMox. Требования к подсистеме хранения такие:

1. кеширование SSD
2. дедупликация при небольшом потреблении памяти. не обязательно inline, можно просто по расписанию.
3. сжатие

Варианты:

1. ZFS - все круто (“искаропки” есть кеширование, дедупликация и сжатие). Однако, дедупликация требует очень много памяти (>5GB на 1Tb данных). А также на производительность влияет неотключаемый Copy-On-Write.
2. ext3/4 over LVM - быстрая и стабильная. можно сделать кеширование на SSD. Нет дедупликации. Нет сжатия.
3. BTRFS over LVM - можно сделать кеширование на SSD. Есть дедупликация по запросу. Есть сжатие. Можно отключить Copy-On-Write (но тогда отключится сжатие).
4. Virtual Data Optimizer - VDO суперштука. Модуль ядра, который реализует inline-дедупликацию и сжатие для томов LVM. Пока что доступен только в RedHat и непонятно что со стабильностью/производительностью/ресурсами. Уже есть в составе Debian - https://manpages.debian.org/testing/lvm2/lvmvdo.7.en.html

Выбор пал на связку BTRFS over LVM. Она позволяет дедуплицировать данные по расписанию (с помощью duperemove), кешировать данные на SSD с помощью lvmcache.
Файлы образов дисков должны быть в формате qcow2, что позволит делать снепшоты.
Файловые системы контейнеров LXC можно хранить как в виде образов, так и просто в папках на BTRFS. Последний вариант будет скорее всего быстрее (вследствие отсутствия loop-устройства), позволит дедуплицировать и\или сжимать файлы контейнеров средствами BTRFS.
Забегая вперед, скажу, что SSD кеш делает виртуальные машины ГОРАЗДО отзывчивее. Даже в условиях нехватки оперативной памяти.

Всем, кто решит использовать BTRFS + lvmcache на хосте ProxMox нужно помнить следующее:

1. lvmcache НЕ совместим с различными вариантами hibernate. Если вы попытаетесь выполнить pm-hibernate на хосте кешированными томами, то никакого hibernate не произойдет. Система просто перезагрузится, а данные на дисках будут повреждены. Я пробывал.
2. использование BTRFS с флагом nodatacow (то есть отключение Copy-On-Write) наверное, немного поднимет производительность, но взамен сделает и без того не самую надежную файловую систему абсолютно неремонтопригодной. Отключится весь функционал, обеспечивающий надежность хранения (CoW и контрольные суммы). В результате, при повреждения файловой системы даже btrfs check использовать не получится (по причине отсутствия ctree).

https://superuser.com/questions/952016/how-can-i-use-one-lvmcache-cache-pool-lv-for-multiple-origin-lvs

Пример конфигурации такой. два диска - /dev/vdb (SSD) и /dev/vdc (HDD). Создаем физичесике тома и группу томов test:

pvcreate /dev/vdb
pvcreate /dev/vdc
vgcreate vgname /dev/vdb /dev/vdc

Создаем том с кешем на SSD:

lvcreate --type cache-pool -L1G -n cache vgname /dev/vdb

Создаем том с данными:

lvcreate -L9G -n data vgname /dev/vdc

И теперь собираем конструкцию:

lvconvert --type cache --cachepool vgname/cache vgname/data
Do you want wipe existing metadata of cache pool volume test/cache? [y/n]: y
Logical volume vgname/data is now cached.

Отсоединить кеш от тома можно командой:

lvconvert --splitcache vgname/data

Состояние тома можно поглядеть командой:

dmsetup -v status vgname/data

Тип кеша можно поменять командами:

lvchange --cachemode writeback vgname/data
lvchange --cachemode writethrough vgname/data

Для начала надо смонтировать том с параметрами noatime,nodiratime

mkdir /mnt/vgname-data
echo '/dev/mapper/vgname-data  /mnt/vgname-data  btrfs   noatime,nodiratime  0  2' >> /etc/fstab
mount /mnt/vgname-data
pvesm add dir Test-Data --path /mnt/vgname-data

Тестовый хост - Pentium Silver J5005, 8GB Ram, mdadm RAID1 2x2Tb Seagate HDD (подключены к SoC AHCI), OCZ Vertex2 EX 100Gb SSD Cache (подключен к ASMedia ASM1061), transparent_hugepage выключены.
FIO под Windows Server 2008R2 скачанный отсюда: https://bluestop.org/fio/ у меня не заработал. Все время при запуске падал - fio.exe has stopped working.
Очевидно, это проблемы со сборкой, потому что FIO скачанный отсюда: https://ci.appveyor.com/project/axboe/fio/build/job/1q9lno301yq74mxc/artifacts заработал без проблем.
Тесты запускались такими командами:

fio.exe   --name=baseline --rw=randread --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall
fio.exe   --name=baseline --rw=randwrite --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall

То есть тест блоками по 4k, случайные чтение и запись, глубина очереди 32, размер тестового файла - 1Gb, без кеширования на уровне Windows (direct=1).
Тесты запускались по три раза, чтобы тестовый файл попал в SSD-кеш.

• Предсказуемо, стабильно высокие результаты при минимальной загрузке VCPU показал вариант, когда включено кеширование на LVM и Proxmox в режимах WriteBack. Его недостатком можно считать вероятность потери данных при выходе из строя SSD или отключении питания.
• Не сильно отстает конфигурация с кешированием только на SSD в режиме WriteBack. От выхода из строя SSD можно защититься, использовав два накопителя в зеркальном массиве.
• Разница между форматами qcow2 и raw несущественна, при большей функциональности qcow2.
• В режимах Writeback на уровне proxmox без кеширования на SSD на уровне lvm, скорость записи очень нестабильна. Она может быть как довольно высокой (3000-4000 IOPS), так и довольно низкой (500-1000 IOPS) и меняется произвольным образом.
• Режимы кеширования ProxMox WriteThrough - существенно ускоряют чтение (в 100 раз), но замедляют запись (в 5-20 раз) по сравнению с режимами без кеширования и writeback.
• Возможно, на данной системе можно добиться более высоких результатов, если подключить cache SSD к SoC AHCI. Вот тут есть тестирование производительности разных контроллеров: http://www.thg.ru/storage/vliyaniye_kontrollera_na_skorost_ssd/print.html и ASMedia ASM1061 там далеко не лидер по производительности, а сам SSD по паспорту способен выдавать до 70000 IOPS. C PCI-E SSD результаты должны быть еще интереснее.

Тестирование производилось на VM - Windows Server 2008 R2, 4GB mem, 2 cores. Для тестирования виртуальной машине добавлен отдельный пустой диск 32Gb.
В качестве SSD cache выступал том LVM на SATA диске OCZ Vertex V2 EX.
Тест в Crystal Mark запускался по 3 раза, чтобы данные успевали закешироваться. В таблице приведены данные после третьего замера.
Параметры CrystalMark - 5, 1GiB.
Boot Time - время загрузки ОС от включения до появления приглашения Press Ctrl+Alt+Del.

1 - lvm cache - On WriteBack, proxmox cache - no cache, qcow2
2 - lvm cache - On WriteBack, proxmox cache - no cache, raw
3 - lvm cache - On WriteBack, proxmox cache - WriteBack, qcow2 . WARNING - Very High CPU Load while tests!!! Very Long test!!!
4 - lvm cache - On WriteBack, proxmox cache - WriteThrough, qcow2 WARNING - Very High CPU Load while tests!!! Very Long test!!!
5 - lvm cache - On WriteBack, proxmox cache - WriteThrough, raw WARNING - Very High CPU Load while tests!!! Very Long test!!!
6 - lvm cache - On WriteBack, proxmox cache - WriteBack, raw . WARNING - Very High CPU Load while tests!!! Very Long test!!!