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-fotosRWBeschikbare 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.
Eén antwoord op “LVM thin pool extension”