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

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

LVM thin pool extension, v2

Het verhaal van vorige keer dat een van de data-LV’s bijna vol zat is wat lang van tekst en niet volledig van uitleg, nu een poging voor een puntsgewijze howto.

Het gaat deze keer om de video-LV. Een DV-tapes neemt ongeveer 15 GB in beslag, en er was niet meer voldoende ruimte voor de eerste vakantie-tape.

Gebruikte commando’s

# df-h /home/wbk/movies 
# lvs -a data/videoRW -o+thin_count,thin_id,devices
# vgs data -o+pv_name,pv_free
# pvs /dev/sde1 -a -o-vg_name -o+vg_name,vg_size,vg_free,lv_name,origin,pool_lv,data_lv
# lvextend -r -L+200G data/videoRW /dev/sde1

Huidige status afleiden

Eerst df -h om de juiste LV bij de volle directory/partitie te vinden. De movies-directory heeft nog 13 MB vrij in LV data-videoRW :

df -h /home/wbk/movies
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.3T  1.3T   13M 100% /home/wbk/movies

Daarna de LVM-status erbijzoeken; /dev/mapper/data-videoRW is een van de vijf thin LV’s onder datatlvpool, namelijk nummer 4 (onderaan). videoRW heeft zelf geen (hardware-) device, omdat het een logisch volume in een logisch volume is.

Het feitelijke (hardware-) device waarop de data terecht komt, kan gevonden worden via de thin pool, hier datatlvpool.

Omdat videoRW een thin LV is, kan de in df -h gerapporteerde vrije ruimte groter zijn dan de daadwerkelijke beschikbare ruimte op de onderliggende fysieke volumes. Dat is voor videoRW (nog) niet aan de orde: datatlvpool heeft nog 8% van 800 GB, ~64 GB, vrije ruimte.

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                     

De conclusie is wel: om de vakantietapes van dit jaar over te zetten op schijf, moet naast het videoRW-volume, ook het datatlvpool-volume groter gemaakt worden. Voor metadata is nog voldoende ruimte: datatlvpool_tmeta heeft nog maar 200 MB van 400 MB gebruikt.

Hoeveel ruimte is er om datatlvpool groter te maken? Dat hangt van de vrije ruimte in de volumegroep data af, en uiteindelijk van de vrije ruimte van de onderliggende fysieke volumes. De data van datatlvpool zit in het data-component van het volume, datatlvpool_tdata, met als onderliggend (handmatig toegewezen) fysiek volume /dev/sde1.

# vgs data -o+pv_name,pv_free
  VG   #PV #LV #SN Attr   VSize VFree  PV         PFree   
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda1    18.07g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda2     9.80g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda3   <60.00g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sdd4    <2.00g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sdb4    <7.51g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda9  <328.67g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sde1     1.22t

Het rapport voor PV /dev/sde1 laat zien dat sde1 deel uitmaakt van VG data. Die VG heeft (in totaal) 1.6 TB vrije ruimte, de (enige) toegewezen LV is datatlvpool_tdata

# pvs /dev/sde1 -a -o-vg_name -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/sde1  lvm2 a--  <2.00t 1.22t data 7.31t <1.64t [datatlvpool_tdata]                 
  /dev/sde1  lvm2 a--  <2.00t 1.22t data 7.31t <1.64t                                     

De grootte van pool datatlvpool kan automatisch bijgewerkt worden door LVM, zie Automatically extend thin pool LV in man 7 lvmthin, maar voor de thin volumes zelf zie ik het niet 1-2-3. Die moet dus handmatig vergroot worden. Controle van de gemonitorde pool:

# lvs data/datatlvpool -o+seg_monitor
  LV          VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor  
  datatlvpool data twi-aot--- 798.21g             92.02  47.56                            monitored

Extend thin volume videoRW

Automatische uitbreiding van de thin volumes kan ook aangezet worden, zie man 7 lvmthin , Automatic extend settings.

Waarschijnlijk heb ik het, bang voor ongemerkt volschrijven van de VG, uitgezet. De standaardsetting is dat de thinLV bij 70% uitgebreid wordt, met 20%. Dat kun je uitzetten door in /ect/lvm/lvm.conf de optie thin_pool_autoextend_threshold op 100 te zetten. Dat staat hij op het moment, en met dezelfde overweging laat ik hem daar op staan.

# lvextend -tvr -L+200G data/videoRW /dev/sde1
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Executing: /sbin/fsadm --dry-run --verbose check /dev/data/videoRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-videoRW
    Test mode: Skipping archiving of volume group.
    Extending logical volume data/videoRW to <1.43 TiB
  WARNING: Sum of all thin volume sizes (<4.87 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<1.64 TiB).
  Size of logical volume data/videoRW changed from 1.23 TiB (323584 extents) to <1.43 TiB (374784 extents).
    Test mode: Skipping backup of volume group.
  Logical volume data/videoRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/videoRW 1535115264K
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Device "/dev/mapper/data-videoRW" size is 1357209665536 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-videoRW"
fsadm: Resizing filesystem on device "/dev/mapper/data-videoRW" to 1571958030336 bytes (331350016 -> 383778816 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-videoRW 383778816

dsadm: Skipping filesystem check : Het bestandssysteem is aangekoppeld; fsck kan geen kwaad dus ik unmount het.
WARNING: Sum of thin volumes exceeds thin pool: Ik vermoed dat in de 4.77 TB ook de RO-origins opgenomen zijn, anders zit ik volgens mij nooit tegen de 5 TB aan mediabestanden. Alhoewel… fotosRW geeft aan 3.27 TB, waarvan 15.21% bezet is. Dat zou redelijk passen in een totaal van ~5 TB waarvan minder dan 1.5 TB bezet is.

Nu voor ’t echie:

# lvextend -r -L+200G data/videoRW /dev/sde1  
fsck from util-linux 2.36.1
...
filmNR: Inode 54001666 extent tree (at level 2) could be narrower.  IGNORED.
filmNR: Inode 55050243 extent tree (at level 1) could be shorter.  IGNORED.
...
filmNR: Inode 60030985 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: 5000/82837504 files (23.6% non-contiguous), 328700572/331350016 blocks
  WARNING: Sum of all thin volume sizes (<4.87 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<1.64 TiB).
  Size of logical volume data/videoRW changed from 1.23 TiB (323584 extents) to <1.43 TiB (374784 extents).
  Logical volume data/videoRW successfully resized.
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/data-videoRW to 383778816 (4k) blocks.
The filesystem on /dev/mapper/data-videoRW is now 383778816 (4k) blocks long.

De beschikbare ruimte in de volumegroup data is nog steeds 1.64 TB, er is immers enkel beschikbare ruimte toegewezen aan de thin LV videoRW, maar nog niets gebruikt.

Het resultaat

Er is nu voldoende ruimte voor zo’n 12 uur aan DV-video:

# df -h /home/wbk/movies/
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.5T  1.3T  206G  86% /home/wbk/movies

Print this entry

LVM thin pool extension

De foto-LV zit bijna vol, nog 32 GB te gaan. Er is meer ruimte nodig: om Nextcloud op online te kunnen upgraden naar de laatste versie, heb ik daar ruimte voor een backup nodig, en dat lukt niet met het huidige aantal (en grootte van) bestanden. De foto’s gaan daarom voor een groot deel naar de andere machine, maar 32 GB is niet voldoende.

De foto’s staan op een samengesteld volume:

  • cache_fotos , een caching-LV op twee SSD’s:
    • cache_fotos_cmeta
    • cache_fotos_sdata
  • data-LV, bestaand uit
    • fotosRO , een read-only LV op langzame SMR schijf
    • fotosRW, een thin LV met ‘external origin’ fotosRO, zelf een beschrijfbaar LV in LV datatlvpool. Die datatlvpool heeft twee onderliggende LV’s
      • datatlvpool_tmeta
      • datatlvpool_tdata

Er kan dus op vijf punten te weinig ruimte ontstaan:

  • fotosRW
  • datatlvpool_tmeta
  • datatlvpool_tdata
  • cache_fotos_cmeta
  • cache_fotos_cdata

Om te controleren op beschikbare ruimte:

  • df -h | grep fotos RW voor LV fotosRW
    df -h | grep fotosRW
    /dev/mapper/data-fotosRW 2.9T 2.8T 32G 99% /home/wbk/photos
    • de 32G zou meer mogen zijn
    • de 99% zou minder mogen zijn
  • lvs -a data |grep twi voor de thin pool
    lvs -a data |grep twi
    datatlvpool data twi-aot— 409.60g 85.25 37.98
    • 85.25 is het percentage tdata in gebruik, er is dus nog ~60 GB (15% van 400 GB) beschikbaar voor alle thin LV’s in deze pool
    • 37.98 is het percentag tmeta in gebruik, er is nog ~150 MB (60% van 250 MB) beschikbaar voor het beheer van de thin LV’s in deze pool
  • lvs -a data |grep Cwi—C voor de cache-LV:
    lvs -a data |grep Cwi—C
    [cache_fotos] data Cwi—C— 48.00g 81.11 9.16 0.00
    • 81.11 is het percentage cdata in gebruik, er is ~10 GB (20% van 48 GB) beschikbaar voor aanvullende caching voor de fotos. Het lijkt dat enkel fotosRO caching heeft, lvs -a |grep C— geeft alleen de -RO LV’s terug
    • 9.16 is het percentage cmeta in gebruik, er is nog 90 MB (90% van 100 MB) beschikbaar voor beheer van het cache

Het belangrijkste is de ruimte op datatlvpool. Als er geen tdata of tmeta meer beschikbaar is, kan het bestandssysteem op fotosRW kapotgaan. Het lijkt of er nog gewoon naar het bestandssysteem geschreven kan worden, er lijkt in dat geval immers nog ruimte beschikbaar. Normaliter wordt de pool automatisch verruimd op het moment en met de percentages vermeld in /etc/lvm/lvm.conf

  • thin_pool_autoextend_threshold = 95
  • thin_pool_autoextend_percent = 10

Het verantwoordelijke proces daarvoor is dmeventd. Controleer of de pool gemonitord wordt door dmeventd met lvs -o+seg_monitor | grep monitored
Met de huidige instellingen wordt dmevendt pas over 40 GB getriggerd de pool te verruimen met 30 GB. Dat kan doorgaan zolang er voldoende ruimte in de bovenliggende VG is. VG data heeft 2 van 7 TB beschikbaar.

Het makkelijkst valt ruimtegebrek op fotosRW op: er kunnen geen bestanden meer naar het bestandsysteem geschreven worden, ‘disk full’. Zolang er nog ruimte in de datatlvpool beschikbaar is, kan het vergroot worden met een simpele lvextend -rL+100G /dev/mapper/data-fotosRW

Geen ruimte op caching-LV’s geeft geen directe problemen: er wordt minder optimaal gecached, maar bestaande cache blijft werken (of misschien wordt de data aangepast om nieuwe/andere bestanden te cachen). Ook het volledig wegvallen van cache geeft enkel een snelheidsvermindering en heeft geen dataverlies tot gevolg.

Afwachten

Deze keer ga ik enkel fotosRW meer ruimte geven, en in de gaten houden wat datatlvpool doet. Met de kennis van nu, verwacht ik dat er nog niets gebeurt op het moment dat fotosRW meer ruimte toegewezen krijgt, maar dat tijdens het verplaatsen van foto’s van Nextcloud naar fotosRW er meermaals een dynamische toewijzing van ruimte aan datatlvpool plaatsvindt.

Terugzoeken van details: zie man 7 lvmthin

Proef op de som

Om de boel in de gaten te houden, heb ik eerst fotosRW groter gemaakt het het bestandssysteem mee laten groeien:

lvextend -rL+100G /dev/mapper/data-fotosRW

Beschikbare vrije ruimte de fotopartitie is toegenomen, terwijl er van VG data geen vrije ruimte afgesnoept is:

root@fractal:~# df -h | grep  -E 'fotosRW|Use'
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW        3.0T  2.8T  128G  96% /home/wbk/photos

root@fractal:~# vgs data            
  /dev/sdd: open failed: No medium found
  VG   #PV #LV #SN Attr   VSize VFree 
  data   7  14   0 wz--n- 7.31t <2.02t

Daarna foto’s kopieren in groepjes van zo’n 5 GB. Net bij het laatste groepje is de 95% aangetikt. De toewijzing van extends uit VG data aan thin LV pool datatlvpool lijkt niet onmiddelijk te zijn, je kan de toewijzing zien groeien door met enige tussenpoos opnieuw de status van VG’s en LV’s op te vragen:


# Bij afronden laatste batch van de initiele set foto's: 
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 409.60g                               94.73  41.80
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         7.48   
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

# Even later is te zien dat onder 'Data%' de waarde van 94.73 teruggelopen is naar 89.91...
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 450.56g                               89.91  43.48  
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         8.05       
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

# ...en nog weer 
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 495.62g                               87.38  46.21                           
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         8.96  
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

  

Beschikbare vrije ruimte in VG data is afgenomen:

                             
root@fractal:~# vgs data
  /dev/sdd: open failed: No medium found
  VG   #PV #LV #SN Attr   VSize VFree
  data   7  14   0 wz--n- 7.31t 1.93t

Conclusie: het systeem werkt. Ik weet niet of het nadelig is om meermaals kleine brokjes toe te kennen, in plaats van in een keer een veel groter stuk. Nu staat met 87% bezetting de volgende verruiming van datatlvpool alweer voor de deur.

Print this entry