Maand: november 2023

Geplaatst op

LVM thin pool extension v3

Na het eerste artikeltje en een tweede versie, nu een deel drie.

  • deel 1 was erg uitgebreid, meer een verkenningstocht
  • deel 2 was gericht op specifieke commando’s en checks, maar ging in op het vergroten van een thin volume
  • deel 3, deze tekst, gaat over het vergroten van de pool zelf, om meer ruimte te bieden aan de thin volumes.

In het kort

Controleer of er voldoende ruimte is op het physieke volume:

# pvs /dev/sdd1 -a -o+vg_name,vg_size,vg_free,lv_name,origin,pool_lv,data_lv
  PV         Fmt  Attr PSize  PFree   VG   VSize VFree  LV                  Origin Pool Data
  /dev/sdd1  lvm2 a--  <2.00t 985.57g data 7.31t <1.38t [datatlvpool_tdata]                 
  /dev/sdd1  lvm2 a--  <2.00t 985.57g data 7.31t <1.38t

Er is nog 986 GB vrij op sdd1; vergroot de thin pool door toewijzing van ruimte specifiek op deze partitie:

# lvextend -L+500G data/datatlvpool /dev/sdd1

Indien nodig een thin volume groter maken; vanwege verschillende eigenschappen van de onderliggende media, vergroten op specifieke PV: 

# lvextend -r -L+200G data/fotosRW /dev/sdd1
fsck from util-linux 2.36.1
foto: Inode 974452 extent tree (at level 1) could be shorter.  IGNORED.
foto: 297302/3427840 files (37.7% non-contiguous), 829469850/877497344 blocks
  WARNING: Sum of all thin volume sizes (5.06 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<911.36 GiB).
  Size of logical volume data/fotosRW changed from <3.27 TiB (856931 extents) to 3.46 TiB (908131 extents).
  Logical volume data/fotosRW successfully resized.
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/data-fotosRW to 929926144 (4k) blocks.
The filesystem on /dev/mapper/data-fotosRW is now 929926144 (4k) blocks long.

Toelichting

De grootte van het beschrijfbare deel van de pool is nu 1,5 TB. In de onderstaande ‘snapshots’ zie je de grootte toenemen (van LV datatlvpool) van 798 TB via “<1.04t” naar de huidige “<1.53t”.

Na v1

root@fractal:~# lvs -a data -o+thin_count,thin_id,devices
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert #Thins ThId Devices
archief data -wi-a----- 800.00g /dev/sda9(0)
[cache_fotos] data Cwi---C--- 48.00g 99.99 9.16 0.00 cache_fotos_cdata(0)
[cache_fotos_cdata] data Cwi-ao---- 48.00g /dev/sdd4(0)
[cache_fotos_cmeta] data ewi-ao---- 100.00m /dev/sdb4(0)
datatlvpool data twi-aot--- 798.21g 92.02 47.56 5 datatlvpool_tdata(0)
[datatlvpool_tdata] data Twi-ao---- 798.21g /dev/sde1(0)
[datatlvpool_tmeta] data ewi-ao---- 400.00m /dev/sdb4(10265)
fotosRO data ori-a-C--- 2.68t [cache_fotos] [fotosRO_corig] 99.99 9.16 0.00 fotosRO_corig(0)
[fotosRO_corig] data owi-aoC--- 2.68t /dev/sda1(1)
fotosRW data Vwi-aot--- <3.27t datatlvpool fotosRO 15.21 5
geluidRO data ori-a----- 16.56g /dev/sda1(703333)
geluidRW data Vwi-aot--- 16.56g datatlvpool geluidRO 5.19 1
[lvol0_pmspare] data ewi------- 400.00m /dev/sda1(707573)
muziekRO data ori-a----- 150.00g /dev/sda2(1)
muziekRW data Vwi-aot--- 150.00g datatlvpool muziekRO 26.97 2
pubNR data ori-a----- 8.00g /dev/sda2(323587)
pubRW data Vwi-aot--- 8.00g datatlvpool pubNR 0.01 3
romRO data -wi-ao---- 90.00g /dev/sda3(1)
ssdata data -wi-ao---- 40.00g /dev/sdb4(25)
videoRO data ori-a----- <1.09t /dev/sda2(38402)
videoRW data Vwi-aot--- 1.23t datatlvpool videoRO 14.56 4

Na v2

root@fractal:~# lvs -a data -o+thin_count,thin_id,devices
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert #Thins ThId Devices
archief data -wi-a----- 800.00g /dev/sde9(0)
[cache_fotos] data Cwi---C--- 48.00g 99.99 9.18 0.00 cache_fotos_cdata(0)
[cache_fotos_cdata] data Cwi-ao---- 48.00g /dev/sda4(0)
[cache_fotos_cmeta] data ewi-ao---- 100.00m /dev/sdb4(0)
datatlvpool data twi-aot--- <1.04t 89.09 45.29 5 datatlvpool_tdata(0)
[datatlvpool_tdata] data Twi-ao---- <1.04t /dev/sdd1(0)
[datatlvpool_tmeta] data ewi-ao---- 532.00m /dev/sdb4(10265)
fotosRO data ori-a-C--- 2.68t [cache_fotos] [fotosRO_corig] 99.99 9.18 0.00 fotosRO_corig(0)
[fotosRO_corig] data owi-aoC--- 2.68t /dev/sde1(1)
fotosRW data Vwi-aot--- <3.27t datatlvpool fotosRO 17.55 5
geluidRO data ori-a----- 16.56g /dev/sde1(703333)
geluidRW data Vwi-aot--- 16.56g datatlvpool geluidRO 1.08 1
[lvol0_pmspare] data ewi------- 532.00m /dev/sde1(707573)
muziekRO data ori-a----- 150.00g /dev/sde2(1)
muziekRW data Vwi-aot--- 150.00g datatlvpool muziekRO 33.59 2
pubNR data ori-a----- 8.00g /dev/sde2(323587)
pubRW data Vwi-aot--- 8.00g datatlvpool pubNR 0.01 3
romRO data -wi-ao---- 90.00g /dev/sde3(1)
ssdata data -wi-ao---- 40.00g /dev/sdb4(25)
videoRO data ori-a----- <1.09t /dev/sde2(38402)
videoRW data Vwi-aot--- <1.43t datatlvpool videoRO 21.08 4

Na v3

root@fractal:~# lvs -a data -o+thin_count,thin_id,devices
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert #Thins ThId Devices
archief data -wi-a----- 800.00g /dev/sde9(0)
[cache_fotos] data Cwi---C--- 48.00g 99.99 9.18 0.00 cache_fotos_cdata(0)
[cache_fotos_cdata] data Cwi-ao---- 48.00g /dev/sda4(0)
[cache_fotos_cmeta] data ewi-ao---- 100.00m /dev/sdb4(0)
datatlvpool data twi-aot--- <1.53t 60.58 45.47 5 datatlvpool_tdata(0)
[datatlvpool_tdata] data Twi-ao---- <1.53t /dev/sdd1(0)
[datatlvpool_tmeta] data ewi-ao---- 532.00m /dev/sdb4(10265)
fotosRO data ori-a-C--- 2.68t [cache_fotos] [fotosRO_corig] 99.99 9.18 0.00 fotosRO_corig(0)
[fotosRO_corig] data owi-aoC--- 2.68t /dev/sde1(1)
fotosRW data Vwi-aot--- <3.27t datatlvpool fotosRO 17.55 5
geluidRO data ori-a----- 16.56g /dev/sde1(703333)
geluidRW data Vwi-aot--- 16.56g datatlvpool geluidRO 1.08 1
[lvol0_pmspare] data ewi------- 532.00m /dev/sde1(707573)
muziekRO data ori-a----- 150.00g /dev/sde2(1)
muziekRW data Vwi-aot--- 150.00g datatlvpool muziekRO 33.59 2
pubNR data ori-a----- 8.00g /dev/sde2(323587)
pubRW data Vwi-aot--- 8.00g datatlvpool pubNR 0.01 3
romRO data -wi-ao---- 90.00g /dev/sde3(1)
ssdata data -wi-ao---- 40.00g /dev/sdb4(25)
videoRO data ori-a----- <1.09t /dev/sde2(38402)
videoRW data Vwi-aot--- <1.43t datatlvpool videoRO 21.08 4

Overig

Op LV-niveau kun je een totaal-vrije-ruimte krijgen voor de VG waartoe ze behoren, maar niet zien hoe de toewijzing van LV-extends over de verschillende PV’s is en (dus) ook niet waar je nieuwe groei van de LV wil laten plaatsvinden: 

lvs data -o+vg_free

Zolang de VG bestaat uit identieke PV’s maakt dat niet uit. Als de onderliggende PV’s verschillende eigenschappen hebben, maakt het wel uit en moet je op onderzoek aan welke PV je specifieke LV’s wil toewijzen.

Om van de betreffende VG te zien uit welke PV’s het bestaat, en hoeveel ruimte er nog beschikbaar is per PV om de VG uit te breiden:

vgs data -o+pv_name,pv_free

Daarna gebruik je pvs om van PV’s een redelijk smalle weergave met wat extra informatie te krijgen: 

pvs  -a  -o+vg_free,lv_name,data_lv

Print this entry

Geplaatst op

LVM cache aan bestaande LVM RAID1 mirror toevoegen

Een nieuwe HP Microserver gen8 is ingericht met Proxmox.

Proxmox is geinstalleerd op een RAID1 LVM dat draait op twee uSD-kaartjes: eentje in het op het moederbord geintegreerde slot, en eentje via een adapter in de op het moederbord geintegreerde USB A aansluiting.

Dat was ik volledig vergeten, tot ik me realiseerde waarom `apt dist-upgrade` zo langzaam liep.

In het verdere reilen en zeilen van de server is er weinig aan te merken. Ik maak me wel enige zorgen over het schrijven van logbestanden, en swap heb ik nog niet aangemaakt.

Om het wat te verlichten voor de geheugenkaartjes, voeg ik 1 GB SSD cache toe (op een volume van 18 GB).

Uit te voeren stappen:

  • SSD partitioneren
    • fdisk /dev/sdh
    • bij een ongebruikt/nieuw opslagmedium, g voor GPT partitielabel
    • n voor nieuwe partitie, t voor type lvm, w om op te slaan
  • Partitie aanmerken als LVM-partitie
    • pvcreate /dev/sdh1
  • Fysiek volume toevoegen aan de volumegreop van de rootpartitie
    • vgextend usbsdraid /dev/sdh1
  • Toekomstig caching volume toevoegen aan bestaande volumegroep
    • lvcreate -vn cache_mt_usbsdraid -l254 mt_usbsdraid /dev/sdh1
  • Volume omzetten naar gecached volume, verwijzend naar het caching volume
    • lvconvert --type cache --cachepool cache_mt_usbsdraid /mt_usbsdraid mt_prox_sys

Dat is alles. Bekijk het resultaat met lvs mt_usbsdraid: 

# lvs mt_usbsdraid
  LV          VG           Attr       LSize  Pool                       Origin              Data%  Meta%  Move Log Cpy%Sync Convert
  mt_prox_sys mt_usbsdraid Cwi-aoC--- 18.00g [cache_mt_usbsdraid_cpool] [mt_prox_sys_corig] 0.04   2.10            0.00

Bovenstaand cache heet in LVM-termen ‘dm-cache’. Het cached in de eerste plaats veelgebruikte data voor snellere toegang, en voorziet bovendien in cache voor schrijfacties.

Daarnaast is er ‘dm-writecache’, specifiek voor het cachen van schrijfoperaties. Ik weet niet of een combinatie van dm-cache en dm-writecache mogelijk is, en of er dan een cascade van caches ontstaat bij het schrijven.

Juist voor het schrijven naar de uSD-kaartjes wil ik caching hebben; aan de ene kant voor de snelheid, maar vooral omdat ik bang ben dat de willekeurige schrijfacties naar verschillende logbestanden funest zijn voor de geheugenkaartjes.

Helaas is het voor het toepassen van dm-writecache nodig het volume offline te halen (vgchange -an mt_usbsdraid/mt_prox_sys), waarmee het systeem z’n rootpartitie kwijtraakt. Misschien probeer ik wat de gevolgen zijn op een VM, maar voor een live systeem heb ik er niet zoveel zin in. Wordt allicht vervolgd.

Print this entry