LINUX.ORG.RU
Форум — Admin  

Proxmox. Storage: LVM Thin

 , ,


2

3

Добрался я наконец, и до этого участка возни с хранением виртуалок.
Итак, имею массив на 2,2тб, на котором развернут тонкий пул емкостью 1,8тб.

# lvs -a
 LV                  VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  datar15k            r15k    twi-a-tz--   1.90t             0.00   0.42
  [datar15k_tdata]    r15k    Twi-ao----   1.90t
  [datar15k_tmeta]    r15k    ewi-ao---- 124.00m  
  [lvol0_pmspare]     r15k    ewi------- 124.00m
Проблема - безобразно высокая скорость заполнения раздела с метаданными, и как следствие - проблемы связанные с остановкой IO вплоть до кернелпаник на хосте гипервизора... :(

Гугл и маны по ЛВМ навели на такую идею: увеличить раздел с метаданными - что я и сделал:

lvresize --poolmetadatasize
Сказано - сделано: 
# lvresize --poolmetadatasize +50G r15k/datar15k
  Size of logical volume r15k/datar15k_tmeta changed from 124.00 MiB (31 extents) to 50.12 GiB (12831 extents).
  Logical volume r15k/datar15k_tmeta successfully resized.

# lvs -a
  LV                  VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  datar15k            r15k    twi-a-tz--   1.90t             0.00   0.01
  [datar15k_tdata]    r15k    Twi-ao----   1.90t
  [datar15k_tmeta]    r15k    ewi-ao----  50.12g
  [lvol0_pmspare]     r15k    ewi------- 124.00m

И все бы хорошо, но есть еще такой раздел: [lvol0_pmspare], емкость которого изначально равна [datar15k_tmeta]
Пытался их уравнять при помощи: 

# lvconvert --repair r15k/datar15k
и получил в ответ: 
  Using default stripesize 64.00 KiB.
  WARNING: recovery of pools without pool metadata spare LV is not automated.
  WARNING: If everything works, remove r15k/datar15k_meta0 volume.
  WARNING: Use pvmove command to move r15k/datar15k_tmeta on the best fitting PV.

# lvs -a
  LV                  VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  datar15k            r15k    twi-s-tz--   1.90t             0.00   0.01
  datar15k_meta0      r15k    -wi-a-----  50.12g
  datar15k_meta1      r15k    -wi-a-----  50.12g
  [datar15k_tdata]    r15k    Twi-ao----   1.90t
  [datar15k_tmeta]    r15k    ewi-ao----  50.12g

По-моему какая-то фигня выходит :(
ЧЯДНТ????
Или просто забить на этот спар? (что кажется мне опасным)

← Пересылка email с сервера на gmail - гугл блокирует запросы напрямую как спам
Динамические правила iptables по поднятию интерфейсов →

еще почитал манов.. 

# lvcreate -L 1950G -n datar15k r15k
  Logical volume "datar15k" created.
root@node-g7:~# lvconvert --type thin-pool --poolmetadatasize +16G r15k/datar15k
  WARNING: Converting logical volume r15k/datar15k to thin pool's data volume with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert r15k/datar15k? [y/n]: y
  Converted r15k/datar15k to thin pool.

# lvs -a
  LV                  VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  datar15k            r15k    twi-a-tz--   1.90t             0.00   0.05
  [datar15k_tdata]    r15k    Twi-ao----   1.90t
  [datar15k_tmeta]    r15k    ewi-ao----  16.00g
  [lvol0_pmspare]     r15k    ewi-------  16.00g
что скажете на такой вариант, уважаемые?
не мало ли 16 гигов? (честа свободного есть еще 300-400 гиг) а больше 16 оно говорит не могет...

И еще вопросец - а есть ли смысл к этому прикрутить лвм кеш гигов на 16-32 из рам диска? (памяти свободной есть вагон и телега)

zelenij
() автор топика

позволю себе здесь порассуждать... 

# lvs -a
  LV                  VG      Attr       LSize   Pool        Origin Data%  Meta%  Move Log Cpy%Sync Convert
  datar15k            r15k    twi-aotz--   1.90t                    42.45  2.67
  [datar15k_tdata]    r15k    Twi-ao----   1.90t
  [datar15k_tmeta]    r15k    ewi-ao----  16.00g
  [lvol0_pmspare]     r15k    ewi-------  16.00g
  vm-100-disk-1       r15k    Vwi-a-tz--  50.00g datar15k           57.00
  vm-202-disk-1       r15k    Vwi-a-tz-- 200.00g datar15k           98.48
  vm-203-disk-1       r15k    Vwi-a-tz-- 130.00g datar15k           100.00
  vm-203-disk-2       r15k    Vwi-a-tz-- 200.00g datar15k           57.02
  vm-205-disk-1       r15k    Vwi-a-tz-- 130.00g datar15k           99.27
  vm-502-disk-1       r15k    Vwi-a-tz-- 130.00g datar15k           99.45
  vm-901-disk-1       r15k    Vwi-aotz-- 100.00g datar15k           99.91

Метаданные занимают 2,67% от объема выделенного под них, т.е. от 16гб, то есть около 430мб...
при этом емкость пула стоставляет 1,9тб, и в нем занято 42,5%, т.е. около 810 гб...
в итоге на 810 гигов занятого места - кушается 430 метров метаданных; таким образом, путем нехитрых математических вычислений получаем следующую информацию: емкости 16гб для раздела с метаданными должно хватить на пул в 30 ТБ.
А какого лысого, простите, при создании тонкого пула по умолчанию делается раздел с метаданными всего-то в 120метров (вне зависимости от размера сосздаваемого пула?????)

попахивает масонской ложей и вселенским заговором....

zelenij
() автор топика
5 сентября 2019 г.
Ответ на: комментарий от zelenij

полностью с вами согласен. а так не хотелось разбираться в zfs. но альтернатив похоже что и нет.

anonymous
()
Ответ на: комментарий от zelenij

Ram явно под кэш занимать стоит только в специфических случаях. Ядро уже кэширует, и виртуалка может.

boowai ★★★★
()
Ответ на: комментарий от zelenij

есть ли смысл к этому прикрутить лвм кеш гигов на 16-32 из рам диска?

Когда-то давно игрался с массовой параллельной заменой sed'ом (xargs --max-procs). Tmpfs может загрузить все ядра процессора. Раздел с lvm-кешем в tmpfs практически работал в однозадачном режиме, кеш практически не работал, вся нагрузка шла на hdd. Разбираться не стал, в чем была проблема.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Пересылка email с сервера на gmail - гугл блокирует запросы напрямую как спам
Admin
Динамические правила iptables по поднятию интерфейсов →