Как зарезервировать PV в группе исключительно для кэша?

Так при создании vg, можно же указать девайс, pv, которого разрешено использовать... Не?

Не понял о чем ты. У меня pv на SSD это часть основной vg т.к кэши нельзя хранить в отдельной vg. Проблема в том, что когда делаешь любые действия с lv в этой vg оно автоматом использует все девайсы в группе, а мне надо чтобы SSD не трогало.

pvchange ?

делаешь любые действия с lv в этой vg оно автоматом использует все девайсы в группе,

Все эти команды позволяют указать с какими PV работать, как ты хочешь я понимаю «работать с любыми кроме SSD». Нет такого, вроде из коробки, можно накостылять скриптов, но это неудобно.

А, кажется я понял об чём ты.

В мане lvcreate написано так: lvcreate .... VolumeGroupName [PhysicalVolumePath...] lvextend .... LogicalVolumePath [PhysicalVolumePath[:PE[-PE]]...] Это раз.

Во вторых, если ты при создании vg для данных, указывал конкретный девайс, то ты потом можешь выкинуть из vg - sdd накопитель. vgreduce это умеет делать.

То есть везде можно указать физический носитель. Но сам не пробовал. :)

Да, я хочу чтобы по дефолту работало со всеми кроме SSD, жаль что этого нет. А то у меня 4 рейда там и каждый раз ручками их указывать довольно проблемно.

Во вторых, если ты при создании vg для данных, указывал конкретный девайс, то ты потом можешь выкинуть из vg - sdd накопитель. vgreduce это умеет делать.

Да, походу придется каждый раз при изменении конфига виртуалок либо делать так, либо попробовать указывать несколько PV при lvresize. Надеюсь прокатит.

Не совсем понимаю, зачем нужно это неудобное ограничение на расположение кэша.

У меня не 4ре рейда...

Но в целом, боль то аналогичная. - Я покамест склоняюсь к варианту:

Одни lv, поверх него ext4, а там уже: qcow2. Будет и сжатие (по необходимости, qcow2 в него умеет). Не тормозные снепшоты (в отличии от lvm). И всегда работающий writeback кеш на ssd.

Таким образом, я надеюсь переложить некоторый overhead от ext4+qcow2, на скорость ssd и не иметь попоболей с дурацкими ограничениями кеширования в lvm. Не понимаю, почему они не научили dm-cache кешированию на уровне vg.

Будет и сжатие (по необходимости, qcow2 в него умеет).

Ты уверен? Откуда там нормальное сжатие?

Да из коробки сжатие. Пережимаешь qcow2 через утилиту конверта и всё. Был у меня образ: 20гб., стал: 7,8гб. Как-то так. Запускал CrystalDiskMark - есть ухудшения, процентов на 10. В моём случае не очень критично. То есть скажем, для почтового сервера - вижу смысл использовать сжатие. Для СУБД - не вижу смысла. Как-то так.

Ну у меня с виртуалками ранее было так: есть изначально настроенный образ системы хорошо сжат и лежит в read-only. А виртуалька использует backing file который намного медленне растет и который я вливаю в read-only раз в несколько месяцев и соответственно опять пережимаю.

Проблема в том, что в случае вендовых виртуалок это работает очень плохо и без полной преаллокации есть заметная потеря производительности. А если делать полную преаллоакцию, то зачем тогда оверхед в виде QCOW не ясно.

Вопрос масштабов, конечно. Можно использовать raw, расположенным на lvm, а lvm - уже кешированная. В общем, не вижу большого смысла играться с кешированием - в том плане, что отключать, подключать... Туда-сюда...

qcow2 со сжатием, даст бонус в том, что можно в 2-3 раза увеличить емкость кеша, без его физического увеличения...

В общем везде есть свои трейд-оф. Но... Была бы возможность делать кеширование для всего vg - цены бы не было... Но видимо это технически очень не просто сделать, чтобы было красиво и монолитно.

Кстати, а ты не пробовал менять режим кеширования для lvm налету? - Я не смог. У меня lvmconvert орёт как не в себя, что, я ему кормлю не тот кеш пул.

В общем это все не такая уж большая проблема, просто когда сегодня добавил ещё 3 диска второй раз косякнул с кэшами и пришлось после этого разделы отмонтировать. Без этого нельзя их уменьшить ext4 и высвободить место использованное на ssd.

Btrfs вроде можно уменьшать в онлайне, но её тоже стремно использовать.

В общем, не вижу большого смысла играться с кешированием - в том плане, что отключать, подключать...

Без отключения кэша нельзя ресайзить lv, иначе бы не отключал.

Кстати, а ты не пробовал менять режим кеширования для lvm налету?

Нет, не пробовал. Во первых читал о том, что оно не сработает, а во вторых стремно потерять данные.

Почему тогда не bcache?

The compression is read-only. It means that if a compressed sector is rewritten, then it is rewritten as uncompressed data.

я не зря написал про НОРМАЛЬНОЕ сжатие

Не нашёл историй успеха, с bcache+lvm. Можно обойтись и без lvm, конечно... Но тогда фиг знает, чем собственно bcache будет лучше, если не будет возможности делать блочные устройства для виртуалок?

я не зря написал про НОРМАЛЬНОЕ сжатие

Это ОМГ, а не сжатие. Завтра посмотрю подробнее. Если всё действительно так (а оно похоже именно так, так-как я заметил, что у меня qcow пожатый, быстро разрастается), то придётся внутри вирт. машин, использовать zfs. Ну или на хосте, пользоваться zol (но надо как-то обойти глюки, хотябы те, которые удалось выявить при тестировании).

Да уж... В мане яснее ясного в общем то всё написано. Спасибо. qcow2 - УГ.

Я только не понял что ты приклеился к этому сжатию? Диски большие и дешевые — сжатие не нужно.

Ну фиг знает... У меня диски: 2,5 формата, стоят дорого. Тыкать их особо некуда. И есть почта, которая весит фиг знает сколько. Перспектива её ужать в два раза - выглядит очень не плохо. В общем я думаю, вот, что лучше: zol+zol. lvm+cache+ext4. Скажи снепшоты в qcow2, такие же унылые как в lvm? Т.е. каждый снепшот будет просаживать запись в два раза? Может ещё есть варианты? Напирмер: vg+bcache+lv, чтобы избежать ext4+qcow

Снапшоты в qcow2 нормальные, ибо copy-on-write

А на чем у тебя почта? Dovecot сам умеет сжатие, вплоть до xz

Ты почту чем принимаешь (МТА) и чем раздаешь (MDA)?

Да из коробки сжатие.

откуда там сжатие? тем более нормальное на лету? какой алгоритм? все это лохотрон, cow просто не резервирует пустые блоки под нули, но при этом так как это cow постоянно растет, так как она пишет в новые области при каждой cow-ротации.

Без отключения кэша нельзя ресайзить lv, иначе бы не отключал.

почему при отключении кеша и до ресайза томов, не залочить физический волюм (ssd который) на выдачу экстентов

pvchange --allocatable {y|n}

Нифига себе... Неделя откровений на ЛОРе.

откуда там сжатие? тем более нормальное на лету?

Теперь уже понял, что это фейк. Спасибо!

Про сжатие dovecot? Я тебе его тоже хотел предложить, там настройки 2-3 строки прописать, да скрипт для сжатия текущих писем прогнать.

Это не фейк. Это для базового образа, который всегда readonly, а от него строят клоны (thin provisioning)

А если там включить опцию сохранения вложений в отдельную папку, то получится подобие дедупликации за счет однократного хранения вложения, отправленного нескольким адресатам. У меня экономило даже больше, чем сжатие, но включать 2 года назад не стал. Из-за отсутствия механизма удаления файлов, на которые не осталось активных ссылок. Возможно его уже написали.

Не нашёл историй успеха, с bcache+lvm.

А что мешает?

zol+zol

Это zvol на хосте и zfs на госте? нинада так делать.

Да это то я конечно понял сразу. :) Но я в печали. В очень печали. Спасибо!

У меня zimbra, а что там в качестве MDA - не знаю. Что-то своё (вроде).

Мешает то, что bcache-tools, нету в ядре. Надо собирать из исходных кодов (по крайней мере в debian). И мешает то, что на сайте bcache, написано, что оно ещё не production ready

Понятно, а шуму-то было.

Мешает то, что bcache-tools, нету в ядре. Надо собирать из исходных кодов (по крайней мере в debian)

Как это понимать?

$ sudo apt-get install bcache-tools
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  bcache-tools
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 18.4 kB of archives.

$ $ /sbin/modinfo bcache
filename:       /lib/modules/3.16.0-4-amd64/kernel/drivers/md/bcache/bcache.ko
license:        GPL
author:         Kent Overstreet <koverstreet@google.com>
author:         Kent Overstreet <kent.overstreet@gmail.com>
license:        GPL
depends:        
intree:         Y
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions 

Что понятно?

А он разве просто письма хардлинками не умеет хранить? Мне казалось что да.

Слушай, думаю ты как всегда прав. Скорее всего отсутствует необходимый репозиторий с пакетом.

root@pve-init:~# grep -h ^deb /etc/apt/sources.list /etc/apt/sources.list.d/*
deb http://ftp.ru.debian.org/debian jessie main contrib
deb http://security.debian.org jessie/updates main contrib

Ты во истину считаешь, что: mdadm+bcache+vg+lvm, хорошая, адекватная связка? Можешь подсказать, как потом мне добавить дисков в эту связку? Ведь bcache требует форматирование тома.

Нет, не подскажу по bcache — не использую, не было случая

Я в общем то понимаю, что mdadm raid10, худо-бедно расширяется, и в общем то bcache, можно как-то потом расширить - но очко играет. Боюсь, что в продакшене, это реально очково.

Не тормозные снепшоты (в отличии от lvm)

а когда, говоришь, ты столкнулся с этими ограничениями lvm? при активной записи на раздел со снапшотом?