LV – Open Source, Boudewijns angle

19 november 2023

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

3 oktober 202119 november 2023

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

24 juli 2021

Home-lv in thin pool uitbreiden

Mijn /home/wbk zit vol en ik kan niets vinden om te verwijderen, dus: uitbreiden.

TL;DR: controleer of er voldoende ruimte in de VG en in de pool is, daarna:

lvextend -rL +20G /dev/mapper/homes-wbkRW  /dev/sde2

Daarmee wordt de wbkRW-LV (in LV-pool homestlvpool) uitgebreid met 20 GB (-L +20G) op PV sde2, en wordt het bestandssysteem meteen uitgebreid (-r)

/home/wbk is een thin-LV, in de pool homestlvpool (’thin logical volume-pool voor home-directories’). Om de uitbreiding van de LV effectief te laten zijn, moet er nog ondersteunende ruimte in de ondersteunende LV-pool zijn.

Het spoor loopt van mijn homedirectory:

root@fractal:~# mount | grep /home/wbk
/dev/mapper/homes-wbkRW on /home/wbk type ext4 (rw,noatime,stripe=256,data=ordered)
/dev/mapper/data-muziekRW on /home/wbk/music type ext4 (rw,noexec,noatime,data=ordered)
/dev/mapper/data-pubRW on /home/wbk/pubNR type ext4 (rw,noexec,noatime,data=ordered)
/dev/mapper/data-geluidRW on /home/wbk/sounds type ext4 (rw,noexec,noatime,stripe=256,data=ordered)
/dev/mapper/data-fotosRW on /home/wbk/photos type ext4 (rw,noexec,noatime,stripe=256,data=ordered)
/dev/mapper/data-videoRW on /home/wbk/movies type ext4 (rw,noexec,noatime,stripe=32750,data=ordered)

dus /home/wbk = /dev/mapper/homes-wbkRW. Gezien de naam: LV wbkRW bevindt zich in VG homes:

root@fractal:~# lvs homes
LV       VG    Attr       LSize    Pool          Origin         Data%  Meta%  
homeRO       homes ori-a-C---  <27.94g [cache_homes] [homeRO_corig] 6.57   1.36            
homeRW       homes Vwi-aot---  <27.94g homestlvpool  homeRO         3.97                                   
homestlvpool homes twi-aot---  800.00g                              6.42   13.42                           
wbkRO        homes ori-a-C---  <95.13g [cache_wbk]   [wbkRO_corig]  75.98  3.46  
wbkRW        homes Vwi-aot--- <135.13g homestlvpool  wbkRO          37.20  
# welke PV`s zijn erbij betrokken? 
root@fractal:~# vgs homes -o+pv_name
  VG    #PV #LV #SN Attr   VSize  VFree   PV        
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sda4 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sda5 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sdc3 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sdb3 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sde2

De nieuw toegewezen ruimte moet beschikbaar gesteld worden door de ‘snelle’ draaiende schijf, de CMR/PMR WD-disk, en niet de SMR Seagate. Welke van de PV’s is dat?


root@fractal:~# fdisk -l |grep Disk
Disk /dev/sdb: 101.3 GiB, 108711411200 bytes, 212326975 sectors
Disk model: INTEL SSDSA2CW12
Disklabel type: gpt
Disk identifier: CBAB7495-F3C7-4542-BC4F-9C3B5F99E30C
Disk /dev/sdc: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1  
Disklabel type: gpt
Disk identifier: B480C1C9-E7CB-D04D-BDCD-C797ED5F0512
Disk /dev/sda: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: ST6000DM003-2CY1
Disklabel type: gpt
Disk identifier: 9E399DDA-DE30-694B-8440-EEFC55053188
Disk /dev/sde: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EFRX-68M
Disklabel type: gpt
Disk identifier: 0517360C-9C7E-42AB-9CC0-B4ADC825DA36

De schijf op /dev/sde is de WD schijf.

Ter controle: er is 800 GB beschikbaar in homestlvpool. De data in de homes-VG bestaat voor een deel uit read-only data uit de homes-*RO LVs en voor een deel uit gewijzigde data in de homes-*RW LVs. De RO-data gaat niet ten koste van de beschikbare 800 GB in de pool, maar de gewijzigde/geschreven data in de RW LVs wel. De geschreven data kan inet meer zijn dan de som van de *RW LVs, dus nog geen 200 GB. Ruimte zat, dus aan de slag.

root@fractal:~# lvextend -tvrL +20G /dev/mapper/homes-wbkRW  /dev/sde2
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  /dev/sdd: open failed: No medium found
  /dev/sdf: open failed: No medium found
    Executing: /sbin/fsadm --dry-run --verbose check /dev/homes/wbkRW
fsadm: "ext4" filesystem found on "/dev/mapper/homes-wbkRW".
fsadm: Skipping filesystem check for device "/dev/mapper/homes-wbkRW" as the filesystem is mounted on /home/wbk
    /sbin/fsadm failed: 3
    Test mode: Skipping archiving of volume group.
    Extending logical volume homes/wbkRW to <155.13 GiB
  Size of logical volume homes/wbkRW changed from <135.13 GiB (34593 extents) to <155.13 GiB (39713 extents).
    Test mode: Skipping backup of volume group.
  Logical volume homes/wbkRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/homes/wbkRW 162664448K
fsadm: "ext4" filesystem found on "/dev/mapper/homes-wbkRW".
fsadm: Device "/dev/mapper/homes-wbkRW" size is 145093558272 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/homes-wbkRW"
fsadm: Resizing filesystem on device "/dev/mapper/homes-wbkRW" to 166568394752 bytes (35423232 -> 40666112 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/homes-wbkRW 40666112

Lijkt OK; volume is aangekoppeld, dus check van bestandssysteem gaat niet door. Nu zonder -tv:

root@fractal:~# lvextend -rL +20G /dev/mapper/homes-wbkRW  /dev/sde2
  /dev/sdd: open failed: No medium found
  /dev/sdf: open failed: No medium found
  Size of logical volume homes/wbkRW changed from <135.13 GiB (34593 extents) to <155.13 GiB (39713 extents).
  Logical volume homes/wbkRW successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/homes-wbkRW is mounted on /home/wbk; on-line resizing required
old_desc_blocks = 9, new_desc_blocks = 10
The filesystem on /dev/mapper/homes-wbkRW is now 40666112 (4k) blocks long.

root@fractal:~# df -h /home/wbk
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/homes-wbkRW  153G  127G   19G  87% /home/wbk
root@fractal:~#

Print this entry

8 mei 2021

LV uitbreiden

Ohje, de schijf zit vol!

df -hTt ext4|grep videoRW
/dev/mapper/data-videoRW  ext4  1.2T  1.2T  3.2G 100% /home/wbk/movies

Daar past maar een paar minuten film op, laat staan een paar SD-kaartjes met videomateriaal.

Eerst kijken hoe LV videoRW op PV’s gemapt is via de VG data:

# lvs |grep videoRW
  videoRW      data   Vwi-aot---   <1.14t datatlvpool   videoRO         4.79                                   
# vgs data
  VG   #PV #LV #SN Attr   VSize VFree 
  data   7  14   0 wz--n- 7.31t <2.02t
# pvs |grep data
  /dev/sda1  data   lvm2 a--     <2.72t   18.21g
  /dev/sda2  data   lvm2 a--      1.25t    9.80g
  /dev/sda3  data   lvm2 a--   <150.00g  <60.00g
  /dev/sda9  data   lvm2 a--      1.10t <328.67g
  /dev/sdb4  data   lvm2 a--    <48.00g   <7.65g
  /dev/sdc4  data   lvm2 a--    <50.00g   <2.00g
  /dev/sdd1  data   lvm2 a--     <2.00t   <1.60t

Devicenamen kunnen veranderen, eerst stond er een /dev/sde tussen, maar die is nu weg. De WD-schijf die eerst /dev/sde was, is nu /dev/sdd:

# fdisk -l |grep Disk
Disk /dev/sdd: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EFRX-68M

Er is voldoende ruimte in VG data, dus de LV kan meteen uitgebreid worden:

# lvextend -tvr -L+100G data/videoRW /dev/sdd1
  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: Skipping filesystem check for device "/dev/mapper/data-videoRW" as the filesystem is mounted on /home/wbk/movies
    /sbin/fsadm failed: 3
    Test mode: Skipping archiving of volume group.
    Extending logical volume data/videoRW to 1.23 TiB
  WARNING: Sum of all thin volume sizes (4.28 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<2.02 TiB).
  Size of logical volume data/videoRW changed from <1.14 TiB (297984 extents) to 1.23 TiB (323584 extents).
    Test mode: Skipping backup of volume group.
  Logical volume data/videoRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/videoRW 1325400064K
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Device "/dev/mapper/data-videoRW" size is 1249835483136 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-videoRW"
fsadm: Resizing filesystem on device "/dev/mapper/data-videoRW" to 1357209665536 bytes (305135616 -> 331350016 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-videoRW 331350016

Er zijn twee waarschuwingen:

Het bestandssysteem is aangekoppeld, dus fsck is niet mogelijk
Het totaal van de toegewezen ruimte in de thin LV’s is meer dan de beschikbare fysieke ruimte in de VG.

Er is onlangs een fsck gedaan, die sla ik nu over. De ruimte in VG data is nu nog toereikend, dat breid ik later uit. Daar gaat ‘ie:

# lvextend -vr -L+100G data/videoRW /dev/sdd1
    Executing: /sbin/fsadm --verbose check /dev/data/videoRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Skipping filesystem check for device "/dev/mapper/data-videoRW" as the filesystem is mounted on /home/wbk/movies
    /sbin/fsadm failed: 3
    Archiving volume group "data" metadata (seqno 60).
    Extending logical volume data/videoRW to 1.23 TiB
  WARNING: Sum of all thin volume sizes (4.28 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<2.02 TiB).
  Size of logical volume data/videoRW changed from <1.14 TiB (297984 extents) to 1.23 TiB (323584 extents).
    Loading table for data-datatlvpool_tdata (254:54).
    Suppressed data-datatlvpool_tdata (254:54) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:53).
    Suppressed data-datatlvpool_tmeta (254:53) identical table reload.
    Loading table for data-datatlvpool-tpool (254:55).
    Suppressed data-datatlvpool-tpool (254:55) identical table reload.
    Loading table for data-videoRO-real (254:46).
    Suppressed data-videoRO-real (254:46) identical table reload.
    Loading table for data-videoRW (254:60).
    Loading table for data-videoRO-real (254:46).
    Suppressed data-videoRO-real (254:46) identical table reload.
    Loading table for data-videoRO (254:47).
    Suppressed data-videoRO (254:47) identical table reload.
    Not monitoring data/datatlvpool with libdevmapper-event-lvm2thin.so
    Unmonitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Suspending data-videoRW (254:60)
    Suspending data-datatlvpool-tpool (254:55)
    Suspending data-videoRO-real (254:46)
    Suspending data-datatlvpool_tdata (254:54)
    Suspending data-datatlvpool_tmeta (254:53)
    Loading table for data-datatlvpool_tdata (254:54).
    Suppressed data-datatlvpool_tdata (254:54) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:53).
    Suppressed data-datatlvpool_tmeta (254:53) identical table reload.
    Loading table for data-datatlvpool-tpool (254:55).
    Suppressed data-datatlvpool-tpool (254:55) identical table reload.
    Loading table for data-videoRO-real (254:46).
    Suppressed data-videoRO-real (254:46) identical table reload.
    Resuming data-datatlvpool_tdata (254:54).
    Resuming data-datatlvpool_tmeta (254:53).
    Resuming data-datatlvpool-tpool (254:55).
    Resuming data-videoRO-real (254:46).
    Resuming data-videoRW (254:60).
    Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Creating volume group backup "/etc/lvm/backup/data" (seqno 61).
  Logical volume data/videoRW successfully resized.
    Executing: /sbin/fsadm --verbose resize /dev/data/videoRW 1325400064K
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 1357209665536 bytes (305135616 -> 331350016 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-videoRW 331350016
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/data-videoRW is mounted on /home/wbk/movies; on-line resizing required
old_desc_blocks = 73, new_desc_blocks = 79
The filesystem on /dev/mapper/data-videoRW is now 331350016 (4k) blocks long.

root@fractal:~#

De ruimte zou nu tot de zomer uit moeten komen:

# df -hTt ext4|grep videoRW
/dev/mapper/data-videoRW  ext4  1.3T  1.2T  102G  92% /home/wbk/movies

Print this entry

18 april 202115 juni 2022

Schijfmigratie met LVM – huidige/doel-indeling

De computer heeft zes SATA-aansluitingen. Ze zijn allemaal in gebruik en de schijven leken opgebruikt – helemaal vol.
Bij nader onderzoek bleek dat niet helemaal het geval, maar met een set nieuwe en eerder bestelde lege schijven beschikbaar, toch de stoute schoenen aangetrokken.

Dat is de NAS/mediaserver. De andere computer, met Proxmox virtualisatie, heeft een aantal virtuele machines met Yunohost-websites draaien. Met aanvankelijk 0 ervaring met Proxmox, heb ik nu ook andere gedachten over de inrichting van de opslagruimte daar.

De huidige inrichting, wat fysieke schijven betreft:

NAS/mediaserver (6/6 SATA bezet)
- 1x 0,1TB Intel 320 SSD TLC
- 1x 2TB Western Digital Green(CMR)
- 2x 2TB Western Digital Red(CMR)
- 1x 3TB Toshiba/Hitachi Deskstar (CMR)
- 1x 6TB Western Digital Red (CMR)
Proxmox virtualisatieserver (4/4 SATA bezet)
- 1x 1TB Samsung SSD QLC
- 1x 1TB Samsung Spinpoint (CMR)
- 1x 4TB Seagate Barracuda (CMR)
- 1x 6TB Seagate Barracuda (SMR)
Beschikbare opslagmedia
- 1x 0,1TB Intel X25 SSD MLC
- 1x 0,5TB Crucial MX SSD TLC
- 1x 8TB Western Digital ‘Pink’ (white label, red internals) (CMR)

Met passen en meten kan in beide servers 12TB+SSD caching geplaatst worden. Er blijft dan 9TB, verdeeld over 3x2TB + 1x3TB, over voor externe backup, uitbreiding, noodgevallen, of een derde server.

NAS/Mediaserver

De huidige inrichting in meer detail is:

RAID (HDD)
           /   1G R1-PV md0 VG boot   LV boot
 2TB \    |/ 900G R5-PV md2 VG data\  
 2TB - - - - 900G R5-PV md3 VG data-- LV foto
 2TB /    |\ 900G R5-PV md4 VG data/    ,geluid
           \\850G R5-PV md5 VG home   LV wbk,home
            \ 85G R5-PV md1 VG sys    LV /,usr,var
                                        ,log,cache
Single disk (HDD)
       - 1100GB VG film
     / -  100GB VG home
 3TB - -  100GB VG muziek  
     \ -  100GB VG mail
       -  100GB VG pub
       \ 1500GB free

      /- 5000GB incremental backup
 6TB -
      \- 1000GB data rescue oude schijven

Single disk (SSD) 
 0,1TB handmatig toegewezen config, databases, cache

De nieuwe inrichting wordt:

SSD
 0,1TiB
   - Swap
   - LVM metadatacache 1% van LVM cache
   - LVM writecache? 
   - MD RAID1 /boot
   - Databases
 0,5TiB
   - Swap
   - LVM datacache ~5% van LVM data
     - 230G voor PMR 5,5TiB
     -  30G voor VG system
     -  20G voor VG homes
     -  50G voor VG data
   - MD RAID1 /boot

Disk drive
 5,5TiB SMR: bestaande data -> veel lezen
  - 5200G VG data  : 
          LV foto
           , film
           , muziek
           , rom
   - 200G VG home
          LV per user, LVM thin
   - 100G VG system : 
          LV root 
           , usr
           , var 
           , varlog
           , varcache
   -  0,5G MD RAID1 /boot

 5,5TiB CMR: nieuwe data -> veel schrijven
   - 2000G VG data
           LV als boven, LVM thin
   - 1200G VG home 
           LV per user, LVM thin
   - 2000G VG infra 
           LV mail
            , vm 
            , backup 
   -  100G VG system
           LV als boven

Waar blijft de opslagruimte

De getallen tellen niet helemaal lekker op. Een HDD van 6TB heeft 5,5TiB beschikbare ruimte.
LVM metadata gebruikt een deel van de VG, waardoor de optelsom van alle PV/VG meer is dan de optelsom van de toegewezen ruimte in de LV’s.
Het bestandssysteem op de LV’s die als partitie beschikbaar komen, gebruikt ook weer wat administratieve ruimte.

Na krap tien jaar hebben de LV’s in de system-VG een stabiele grootte:

Gebruikt vs toegewezen per LV / mountpoint
- / 2G gebruikt van 15G toegewezen
- /usr 15G gebruikt van 15G toegewezen
- /var 18G gebruikt van 20G toegewezen
  - /var/www is voor een groot deel op andere partities gemount, onder LV’s in VG data
- /var/log 3G gebruikt van 7G toegewezen
- /var/cache 2G gebruikt van 3G toegewezen
Totaal 40G gebruikt van 60G toegewezen in LV’s; de VG heeft een grootte van 80G (dus 25% overhead).
In de nieuwe inrichting wordt de VG 100G, is er dus enige ruimte voor groei.

Van alle LV’s is ‘foto’ het meeste gegroeid, en neemt de groei per jaar toe. De afgelopen 20+ jaar neemt 3000G in beslag, gemiddeld 150G per jaar, maar alles van voor 2009 zit daar een orde van grootte onder, terwijl 2012 het laatste jaar met minder dan 200G is. Vanaf 2019 fotograferen we met z’n tweeen, en neemt de beschikbare opslagruimte versneld af. Komende jaren zal het aantal mediaproducenten verdubbelen. Als ik reken met 500G per jaar, dan kunnen we met het voorstel hierboven tot 2025 uit.

Caching

LVM kan zowel voor de data als voor de metadata cache inzetten. Met het bulk aan opslagruimte op trage HDD’s en enkele procenten daarvan op snellere SSD’s, ligt het voor de hand om het cache op SSD’s onder te brengen. Door het data-cache en het metadata-cache op verschillende media te zetten, kunnen ze snel parallel gelezen en geschreven worden.

Als voorbereiding op het configureren van LVM cache heb ik een aantal blogs doorgenomen:

Over LVM writecache heb ik weinig gevonden. Vooral voor de data-VG’s op de PMR-schijf zou ik dat willen inzetten.

Als maatstaf wordt voor metadatacache 0,1 procent van datacache aangehouden. Dat komt overeen met grootte van de bestanden die ik vind in /etc/lvm/archive. Voor datacache heb ik geen cijfers gevonden.

De SSD’s van 120GB en 480GB gebruik ik als cache voor de HDD’s; de eerste voor LVM metadata, de tweede voor de data zelf.

In totaal is er ongeveer 10TiB beschikbare ruimte in de bestandssystemen. De SSD is met 0,44TiB nog geen 5% daarvan. De systeem-VG’s zijn veel kleiner dan de data-VG’s, terwijl er vaker van gelezen en naar geschreven wordt.
De systeem-VG is een van de kleinste VG’s, en staat op de langzaamste HDD. De VG krijgt daarom relatief ruime caching, 30G cache op 100G VG.
De data-VG’s worden vrijwel niet met random reads bestookt. Sequentieel lezen van een SMR-disk mag geen probleem zijn, dus LV’s met foto’s en films hebben vooral baat bij schrijfcache. Dat mag, ten opzichte van de volledige grootte van de LV’s, relatief heel klein zijn: 10G cache per TB opslagruimte. Bij de initiele grootte van 3000G dus 30G, voldoende om het grootste deel van SD-kaartjes te cachen bij het importeren.
Home-directories vallen tussen data- en systeem-VG’s in: er zijn vrij veel kleine bestanden en er worden relatief veel bestanden willekeurig geopend. Er worden geregeld aan willekeurige bestanden wijzigingen gedaan. De VG is te groot om naar rato veel cache aan toe te wijzen. Omdat er zowel bij het schrijven als bij het lezen winst te behalen is, wordt de toewijzing wel ruimer dan bij de data-VG’s

In de eerste instantie doe ik een vrij grove toewijzing op de helft van de SSD voor de SMR schijf. Die schijf wordt als eerste in gebruik genomen, en heeft het meeste baat bij caching. Dus:

230GB cache toewijzen aan volume groups op de PMR schijf
system: 30G cache op 100G volume group
home: 20G op 200G volume group
data: 50G cache op 5200G volume group
latere toewijzing: 100G over voor deze schijf
cachemode instellen met lvconvert –cachemode wrideback om enkel naar cache te schrijven

RAID

Er komen twee software RAID devices via mdadm. Voorheen deed ik het inrichten van mdadm zelf. In dit geval laat ik het management aan LVM over, door lvmraid te gebruiken via

RAID1 /boot, over vier schijven. Het is maar een paar honderd MB. Op die manier maakt het niet uit welke opslagmedium uit het systeem gehaald wordt, er kan in ieder geval een begin met de start van het systeem gemaakt worden.
RAID1 ‘systeem’-partities over de twee HDD’s. Het resulterende RAID-device wordt als PV vrijgegeven in de system-VG, daarin LV’s voor /, /usr, /var, /var/log en /var/cache.
Zorg dat er geschreven wordt naar de snelste schijf, –write-mostly en –write-behind
commando: lvcreate –type raid1 VG [PV’s]
lvcreate –type raid1 system /dev/sdxn /dev/sdym
Zorgen dat de writes initieel (–write-mostly) naar PMR gaan, en lezen van hetzij PMR of SMR. Is te combineren met –write-behind ‘aantal’. Het is me niet duidelijk of write-mostly betekend “deze PV vooral voor schrijven gebruiken, de rest is niet zo snel”, of “deze PV niet voor lezen gebruiken, want het is een traag beestje”.
commando: lvchange –writemostly PV LV
VG ‘system’ opnemen in RAID1 met de CMR-schijf. Voor hints, zoek naar ‘–write-mostly’ en ‘–write-behind’ opties voor mdadm.

OverlayFS

De partities in de data-VG wil ik via bind mount beschikbaar maken in de home-directories als read-only. Wijzigingen en eigen toevoegingen zouden met AUFS toegevoegd worden aan een geintegreerde weergave.

AUFS is niet meer in ontwikkeling, in plaats daarvan is OverlayFS beschikbaar in de kernel.

Thin provisioning

Thin provisioning betekent eigenlijk ‘meer beloven dan je hebt’. Uit een pool van 100G worden bijvoorbeeld drie logische volumes van 50G gemaakt. Ieder van die partities mag naar hartelust beschreven worden, er wordt telkens een stukje van de gemeenschappelijke reserve afgesnoept. Zolang de VG op tijd verruimd wordt, en er op tijd schijven bijgeplaatst worden om PV’s toe te voegen, is er niets aan de hand.

https://www.systutorials.com/docs/linux/man/8-lvconvert/Het voordeel is, dat je voor een set van 7 logische volumes niet van tevoren hoeft te bedenken hoeveel ruimte ze gaan gebruiken. In de oude opstelling was thin provisioning een uitstekende keuze voor de system-VG geweest, met als enig nadeel dat een defect stuk hardware of een klapperende verbinding veel logging zou kunnen veroorzaken. Met vast toegewezen LV’s is dan op een gegeven moment /var/log vol, met (beperkte) gevolgen van dien. Met thin provisioned LV’s is niet alleen de ruimte op /var/log vol, maar ook de vrije ruimte op de overige partities in de volumegroep.

Documentatie en voorbeelden heb ik in blogs gevonden:

lvmthin(7) – Linux man pages
LVM Thin Provisioning
Create LVM thin provisioning with SSD cache
lvconvert –discards passdown om discards door te geven aan het onderliggende apparaat

Trim

Zowel voor SSD’s als voor SMR-HDD’s geldt dat beschreven ruimte niet ineens overschreven kan worden.

Voor beide opslagtypes is daarom ’trim’ support in alle lagen van de opslag gewenst: in het bestandssysteem, LVM en, indien van toepassing, RAID.

In hoeverre die ondersteuning er is, moet ik nog uitzoeken/uitvinden. Zoektermen lijken ‘fstrim’, ‘discard’, ‘cascade down’ ; serverfault suggereerd lsblok -D , man 5 lvm.conf, mdmtrim script van cyberax op Github, ‘don`t enable discard, use fstrim.timer’. Zelfde post: (in 2012) Linux kernel became able to support block discards in the setup.

Ook aan denken

Ontdubbeling met lvmdo (data optimizer, deduplication + compression); lvmdo is een project dat onder Red Hat valt door overname van de ontwikkelaar ervan. Op Debian is de benodigde programmatuur nog niet beschikbaar. Op Stackexchange staat een pointer over het bouwen van de kernenmodule onder Debian:

# apt-get install -y build-essential libdevmapper-dev libz-dev uuid-dev python3-yaml 
# git clone https://github.com/dm-vdo/vdo.git 
# make && make install && sudo apt install -t stretch-backports linux-headers-$(uname -r) 
# git clone https://github.com/dm-vdo/kvdo.git 
# make -C /usr/src/linux-headers-`uname -r` M=`pwd` 
# cp vdo/kvdo.ko /lib/modules/$(uname -r) cp uds/uds.ko /lib/modules/$(uname -r) 
# depmod && modprobe kvdo && modprobe uds
# vdo create --name=vdo-data --device=/dev/md0 --vdoLogicalSize=8T
# systemctl start vdo
# vdo status

Algemene LVM links

LVM internals
Development/LVM support

Stappenplan

PMR-schijf indelen

Welke data waar

Ik wil de PMR-schijf eigenlijk vullen met de meest statische data vooraan, en de meest variabele data aan het einde.
Hoe de firmware het intern afhandeld is me niet bekend. Het lijkt me dat er begonnen wordt met schrijven aan de buitenkant (draait het snelste, geeft voor nieuwe gebruikers van de schijf de beste indruk) en dat er telkens verder naar binnen geschreven wordt.

Als de buitenste 80% van de platters beschreven zijn, en bestanden in de buitenste 1% worden gewijzigd, dan moeten gewijzigde sectoren daar gelezen worden en ergens anders herschreven worden. Of op dezelfde plaats, maar dan moet meteen de hele set ‘dakpannen’ vervangen worden.

Aan de andere kant, als de buitenste 80% beschreven zijn en iets aan de binnenste 1% daarvan wordt gewijzigd, dan is er vlakbij nog een hoop vrije ruimte en hoeft er misschien minder geschoven te worden.

Ongeacht of er van buiten naar binnen, of van binnen naar buiten geschreven wordt, ik ben bang voor fragmentatie (of contstante defragmentatie) als datasets met veel wijzigingen erg goed ingepakt zijn.

De voorlopig meest statische data zijn foto’s. (Update april 2021: dat zijn ze niet: bijwerken van tags in Digikam en die wegschrijven naar EXIF van de jpg’s heeft wijzigingen tot gevolg. Zonder daar verder in te duiken, verwacht ik dat slechts een deel van de data wijzight als er tags naar EXIF en dergelijke geschreven worden, en dat de wijzigingen op blokniveau worden afgehandeld, dus niet voor de hele foto op bestandsniveau.) Dat is meteen een grote set, dus een mooie benchmark voor de schijf. Het is te hopen dat er niet altijd eerst een CMR-cache volgeschreven wordt, voordat de schijf gegevens gaat overzetten naar SMR. Als dat cache 50G zou zijn, dan wordt er telkens voor een paar minuten snel geschreven, tot dat cache vol zit, daarna lang wachten om het cache te kopieren en te wissen, en dan opnieuw.

Ongeacht de interne caching: ik denk niet dat externe LVM-caching daarbij gaat helpen: er is alleen een extra emmertje met data dat moet wachten totdat de SMR-schijf z’n werk gedaan heeft.

Methode

Ik heb niet vaak volledig uit te wisselen schijven. Data groeit, maar verplaatst niet vaak van plaats. Waar nodig, volstond dan een move op bestandssysteem niveau.

Voor volledige partities verplaatsen zou rsync een goede optie zijn, of een backup maken en die terugzetten.

In het geval van LVM is er een optie om een schijf (PV) aan een volumegroep (VG) toe te voegen, vervolgens alle extends van een logisch volume (LV) te spiegelen op extends in dezelfde VG op die nieuwe PV, en vervolgens de spiegeling aan de kant van de PV’s op de oude schijf ongedaan te maken.

Het voordeel is ook het nadeel. De huidige LV’s gaan volledig identiek over, ik weet niet zeker of ik voor de systeem-VG dezelfde werkwijze volg: dan heeft root op / nog steeds een hoop vrije ruimte, en is /usr wat krap.

Stap 1, partitionering

# fdisk /dev/sdf
g voor een nieuwe GPT partitietabel; gooit alles weg
n voor nieuwe partities
t voor het type, 20 voor 'Linux filesystem' 
w om wijzigingen op te slaan

Stap 2, Fysiek volume aanmaken en toewijzen aan volumegroep

# # eerst eens in test-modus
# pvcreate -vt /dev/sdf1 
...
# # dan aanmaken
# pvcreate -v /dev/sdf1 
Wiping signatures on new PV /dev/sdf1. Set up physical volume for "/dev/sdf1" with 10485760000 available sectors. Zeroing start of device /dev/sdf1. Writing physical volume data to disk "/dev/sdf1".
Physical volume "/dev/sdf1" successfully created.

# # toevoegen aan volumegroep
# vgextend -vt data /dev/sdf1
... 
# # zonder test 
# vgextend -v data /dev/sdf1
Wiping signatures on new PV /dev/sdf1.
Archiving volume group "data" metadata (seqno 16).
Adding physical volume '/dev/sdf1' to volume group 'data'
Volume group "data" will be extended by 1 new physical volumes
Creating volume group backup "/etc/lvm/backup/data" (seqno 17).
Volume group "data" successfully extended

Er is onvoldoende ruimte (0 extends) beschikbaar om het mirrorlog aan te leggen op de bestaande PV’s van VG data. Er moet eerst ruimte vrijgemaakt worden.

Met lvs is te zien welke LV’s er op VG data huizen. Met df is te zien waar vrije ruimte is.

root@fractal:~# df -hT |grep 'File|foto|geluid'
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/data-fotos ext4 2.7T 2.6T 2.8G 100% /home/wbk/photos
/dev/mapper/data-geluid ext4 46G 39G 5.4G 88% /home/wbk/sounds

vgresize kan de boel kleiner maken, met -r wordt het bestandssysteem ook op maat gemaakt. Zonder -r wordt het bestandssysteem ‘afgeknipt’, en is de boel mogelijk stuk.

lvresize -rvL -5G /dev/data/geluid
Executing: /sbin/fsadm --verbose check /dev/data/geluid
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluid".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-geluid
fsck from util-linux 2.33.1
geluid: 7763/3055616 files (1.1% non-contiguous), 10199026/12206080 blocks
Executing: /sbin/fsadm --verbose resize /dev/data/geluid 43581440K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluid".
fsadm: Device "/dev/mapper/data-geluid" size is 49996103680 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluid"
fsadm: Resizing filesystem on device "/dev/mapper/data-geluid" to 44627394560 bytes (12206080 -> 10895360 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-geluid 10895360
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-geluid to 10895360 (4k) blocks.
The filesystem on /dev/mapper/data-geluid is now 10895360 (4k) blocks long.
Archiving volume group "data" metadata (seqno 17). Reducing logical volume data/geluid to 41.56 GiB
Size of logical volume data/geluid changed from 46.56 GiB (11920 extents) to 41.56 GiB (10640 extents).
Loading table for data-geluid (253:4).
Suspending data-geluid (253:4) with device flush
Resuming data-geluid (253:4).
Creating volume group backup "/etc/lvm/backup/data" (seqno 18).
Logical volume data/geluid successfully resized.

# # spiegelen instellen; default type=raid
# # lvconvert --type raid1 /dev/data/fotos
# # bij m1 wordt er 1 kopie gemaakt, dus op
# # de nieuw toegevoegde PV
# # lvconvert -m1 /dev/data/fotos
# # samengesteld commando:
# lvconvert -m1 /dev/data/fots /dev/sdf1
Are you sure you want to convert linear LV data/fotos to raid1 with 2 images enhancing resilience? [y/n]: yes
Logical volume data/fotos successfully converted.

Sync van de LV’s gaat meteen van start. Na tien minuten:

lvs
LV    VG   Attr       LSize    ...   Cpy%Sync 
boot  boot -wi-ao---- 188.00m
fotos data rwi-aor--- 2.68t          2.19

Volgens htop is vooral rsyslog -n -iNone heel druk, met enkele tientallen procenten CPU. Dat heeft, volgens mij, niets met deze actie te maken (er zit al meerdere uren CPU-tijd in); iotop heeft schrijfsnelheden in tientallen kB/s… niet heel snel.

Aan de andere kant, als het zo doorgaat, dan zit er nog 500 minuten in, en zou er in een halve dag 3TB overgezet zijn. Acht uur later staat de teller op 75%, en laat iotop pieken van 30MB/s zien als ik de machine uit z’n rust haal. Daarna zakt de snelheid weer in naar de kB/s-range. Ik heb het idee dat mdadm/LVM te low-level is voor iotop: firefox is het proces dat meestal bovenaan staat, qua bandbreedte en totaal gebruik, en dat loopt niet in de GB’s.

Het juiste commando blijkt niet iotop, maar iostat:

# # geef eXtended info, in Human-readable formaat over
# # Devices (in tegenstelling tot -c, CPU), ververs na
# # 10 seconden
# iostat -hdx 10 -g read /dev/sd[abc] /dev/md2 -g write /dev/sdf

Daarmee is te zien dat van /dev/sda, /dev/sdb en /dev/sdc telkens zo’n 25MB/s gelezen wordt, uit /dev/md1 die door die drie gevormd wordt zo’n 75MB/s en dat er met dezelfde snelheid naar /dev/sdf1 geschreven wordt.

Uiteindelijk heeft de synchronisatie zo’n 10 uur geduurd voor 3TB, dus de 75MB/s heeft de schijf grofweg volgehouden.

Volgende LV: geluid. Op dezelfde manier:

# lvconvert -m1 /dev/data/geluid /dev/sdf1

In de geluid-partitie zit niet alleen geluid. Er staan een paar ISO’s met C’t-jaargangen. Dat is de helft van de ruimte en moet eigenlijk opgeruimd worden. Daarom een swap-truc tussendoor:

SSD 480GB hot-unplug
HDD 3TB hot-plug
verplaats ISO’s /home/wbk/geluid naar /home/nonraid/tijdelijk
verklein (opnieuw) het geluid LV in VG data
- lvresize -rvL -25G /dev/data/geluid

Vervolg-spiegelacties:

lvconvert -m1 /dev/data-nonraid/muziekNR /dev/sdf1
lvconvert -m1 /dev/data-nonraid/pubNR /dev/sdf1
lvconvert -m1 /dev/data-nonraid/homesNR /dev/sdf1
lvconvert -m1 /dev/data-nonraid/video /dev/sdf1

Wat blijkt? LV’s kunnen alleen binnen dezelfde VG gespiegeld worden. VG’s kunnen ook alleen binnen dezelfde VG verplaatst worden van PV naar PV.

De eenvoudigste optie om de data met LVM-boordmiddelen te kopieren, lijkt:

de bestaande VG ‘data’ op /dev/sdf1 te verkleinen van 5TB naar 3TB
de PV op dezelfde manier te verkleinen
de fysieke partitie net zo verkleinen
nieuwe partitie creeren
nieuwe PV creeren
de nieuwe PV aan VG ‘data-nonraid’ toevoegen
vervolgens via RAID de LV’s spiegelen
RAID-spiegeling voor alle LV’s in VG’s ‘data’ en ‘data-nonraid’ uitzetten
(misschien de ‘oude’ VG’s van naam veranderen)
nieuwe VG ‘data-nonraid’ inactief maken met vgchange -an
nieuwe VG ‘data-nonraid’ en VG ‘data’ samenvoegen met vgmerge

Volgende obstakel: er is geen eenvoudige manier om de grootte van een PV te sturen in een kleinere richting.

Ik denk dat de juiste manier is:

alle physical extends (PE’s) naar het begin van de PV schuiven met pvmove
fysieke partitie kleiner maken, maar niet te klein (voorkom ‘afknippen’ aan de achterkant)
PV automatisch op maat maken met pvresize /dev/sdf1
- als ik pvresize -tv –setphysicalvolumesize 5700000s /dev/sdf1 doe, krijg ik een onduidelijke waarschuwing
- de onduidelijke waarschuwing blijkt expres toegevoegd te zijn, er is een nieuwe prompt om alsnog de resize door te voeren:
  - [root@virt-365 ~]# pvresize –setphysicalvolumesize 100G /dev/sdj -y WARNING: /dev/sdj: Overriding real size 40.00 GiB. You could lose data. WARNING: /dev/sdj: Pretending size is 209715200 not 83886080 sectors. Physical volume “/dev/sdj” changed 1 physical volume(s) resized / 0 physical volume(s) not resized

Over verkleinen van LV’s is een hoop te vinden, over verwijderen van PV’s uit VG’s ook nog wel en hier en daar wat over het vergroten van een PV met pvresize. Verkleinen maar heeeel weinig.

Ik heb mijn geluk beproeft met (KDE) partitionmanager. Tot mijn blijde verrassing wist de partitionmanager niet alleen LVM-volumes te herkennen, maar ook te kunnen beheren. Omdat alle gebruikte PE’s aan het begin van de PV stonden, was de actie snel doorgevoerd.

Verder met het kopieren van data-nonraid LV’s. Voor het uitbreiden van de VG test ik het automatisch aanmaken van de PV:

# vgextend -v data-nonraid /dev/sdf2
Wiping signatures on new PV /dev/sdf2.
Archiving volume group "data-nonraid" metadata (seqno 13).
Adding physical volume '/dev/sdf2' to volume group 'data-nonraid'
Volume group "data-nonraid" will be extended by 1 new physical volumes
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 14).
Volume group "data-nonraid" successfully extended

In een keer raak, behalve dat ik 1.4G, in plaats van 1.4T als partitiegrootte had gekozen. Dus: PV weghalen uit VG, partitie verwijderen, opnieuw toevoegen en VG uitbreiden.

# vgreduce -v data-nonraid /dev/sdf2
Archiving volume group "data-nonraid" metadata (seqno 12). Removing "/dev/sdf2" from volume group "data-nonraid" Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 13).
Removed "/dev/sdf2" from volume group "data-nonraid"

Het gaat niet helemaal lekker na het verwijderen en toevoegen van een grotere partitie. Misschien is er ergens cache blijven hangen, een stukje metadata of het toevoegen van PV’s gaat niet helemaal lekker via vgextend. Als melding:

# vgextend -v data-nonraid /dev/sdf2
Physical volume '/dev/sdf2' is already in volume group 'data-nonraid'
Unable to add physical volume '/dev/sdf2' to volume group 'data-nonraid'
/dev/sdf2: physical volume not initialized.

Na verwijderen uit de VG, opnieuw initialiseren en weer toevoegen, werkte het naar behoren:

# pvcreate /dev/sdf2
Can't initialize physical volume "/dev/sdf2" of volume group "data-nonraid" without -ff
/dev/sdf2: physical volume not initialized.
# vgreduce -v data-nonraid /dev/sdf2
Archiving volume group "data-nonraid" metadata (seqno 14).
Removing "/dev/sdf2" from volume group "data-nonraid"
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 15).
Removed "/dev/sdf2" from volume group "data-nonraid"
# pvcreate /dev/sdf2
Physical volume "/dev/sdf2" successfully created.
root@fractal:/var/log# vgextend -v data-nonraid /dev/sdf2
Wiping signatures on new PV /dev/sdf2.
Archiving volume group "data-nonraid" metadata (seqno 15).
Adding physical volume '/dev/sdf2' to volume group 'data-nonraid'
Volume group "data-nonraid" will be extended by 1 new physical volumes
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 16).
Volume group "data-nonraid" successfully extended
# pvs /dev/sdf2
PV VG Fmt Attr PSize PFree
/dev/sdf2 data-nonraid lvm2 a-- 1.39t 1.39t

Misschien niet de handigste beslissing, maar tijdens het synchroniseren van LV ‘musiek’ ben ik met de KDE partition manager de overige LV’s en PV’s gaan verkleinen, waar mogelijk. Onder water doet die hetzelfde als ik met de hand had moeten doen, zoals in het log te zien is:

Shrink partition ‘/dev/sde2’ from 632.05 GiB to 359.53 GiB
Job: Check file system on partition ‘/dev/sde2’
Command: lvm pvck --verbose /dev/sde2
Found label on /dev/sde2, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=1044480
Check file system on partition ‘/dev/sde2’: Success

Job: Resize file system on partition ‘/dev/sde2’ to 753993728 sectors
Resizing file system from 1325512704 to 753993728 sectors.

Command: lvm pvmove --alloc anywhere /dev/sde2:92040-161804 /dev/sde2:0-92039
No data to move for data-nonraid.

Command: lvm pvresize --yes --setphysicalvolumesize 386044788736B /dev/sde2
WARNING: /dev/sde2: Pretending size is 753993728 not 1325512704 sectors.
Physical volume "/dev/sde2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
Resize file system on partition ‘/dev/sde2’ to 753993728 sectors: Success

Job: Set geometry of partition ‘/dev/sde2’: Start sector: 2237691904, length: 753993728
Set geometry of partition ‘/dev/sde2’: Start sector: 2237691904, length: 753993728: Success

Job: Check file system on partition ‘/dev/sde2’
Command: lvm pvck --verbose /dev/sde2
Found label on /dev/sde2, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=1044480
Check file system on partition ‘/dev/sde2’: Success
Shrink partition ‘/dev/sde2’ from 632.05 GiB to 359.53 GiB: Success

Resize van LV pubNR in VG data-nonraid lukte niet met de KDE partition manager. Niet aangekoppeld, en niet na ontkoppelen. De LV is 100G groot, de ext4 partitie ook, en de gebruikte ruimte is 5G. Zou dus een stuk vanaf kunnen.

Op de command line lukt het wel het ontkoppelde bestandssysteem te minimaliseren met de -M optie:

# # eerst zien wat de minimale grootte (in 'blocks', van 4k voor deze schijf) wordt met -P 
# resize2fs -P /dev/mapper/data--nonraid-pubNR
resize2fs 1.44.5 (15-Dec-2018)
Estimated minimum size of the filesystem: 1852946
# # daarna verkleinen 
# resize2fs -Mp /dev/mapper/data--nonraid-pubNR
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data--nonraid-pubNR to 1852946 (4k) blocks.
Begin pass 2 (max = 735986)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 800)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 29)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/mapper/data--nonraid-pubNR is now 1852946 (4k) blocks long.

Daarna alsnog met lvresize het LV verkleind, en het bestandssysteem vergroot:

# lvresize -vrL8G /dev/data-nonraid/pubNR
Executing: /sbin/fsadm --verbose check /dev/data-nonraid/pubNR
fsadm: "ext4" filesystem found on "/dev/mapper/data--nonraid-pubNR".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data--nonraid-pubNR
fsck from util-linux 2.33.1
pubNR: 645/466944 files (28.1% non-contiguous), 1375989/1852946 blocks
Executing: /sbin/fsadm --verbose resize /dev/data-nonraid/pubNR 8388608K
fsadm: "ext4" filesystem found on "/dev/mapper/data--nonraid-pubNR".
fsadm: Device "/dev/mapper/data--nonraid-pubNR" size is 107374182400 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data--nonraid-pubNR"
fsadm: Resizing filesystem on device "/dev/mapper/data--nonraid-pubNR" to 8589934592 bytes (1852946 -> 2097152 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data--nonraid-pubNR 2097152
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data--nonraid-pubNR to 2097152 (4k) blocks.
The filesystem on /dev/mapper/data--nonraid-pubNR is now 2097152 (4k) blocks long.
Archiving volume group "data-nonraid" metadata (seqno 23). Reducing logical volume data-nonraid/pubNR to 8.00 GiB
Size of logical volume data-nonraid/pubNR changed from 100.00 GiB (25600 extents) to 8.00 GiB (2048 extents).
Loading table for data--nonraid-pubNR (253:16).
Suspending data--nonraid-pubNR (253:16) with device flush
Resuming data--nonraid-pubNR (253:16).
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 24).
Logical volume data-nonraid/pubNR successfully resized.
root@fractal:~# lvs /dev/data-nonraid/pubNR
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
pubNR data-nonraid -wi-a----- 8.00g
# mount /dev/data-nonraid/pubNR
# df -h /dev/data-nonraid/pubNR
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/data--nonraid-pubNR 7.8G 5.1G 2.4G 69% /home/wbk/pubNR

Aansluitend spiegelen:

# lvconvert -m1 /dev/data-nonraid/pubNR /dev/sdf2

De laatste LV in deze VG, homesNR, wil ik niet in de uiteindelijke data-VG hebben, maar in een home-VG. Dus nu eerst de spiegeling ongedaan maken maar LV’s behouden. Dan aan de ‘nieuwe’ kant op /dev/sdf de VG data-nonraid inactief maken en die opnemen in VG data. Als dat klaar is, opnieuw een VG data-nonraid aanmaken om homesNR te spiegelen en die later met een home-VG samen te voegen.

Slitsen lukt niet direct:

lvconvert -tvm0 /dev/mapper/data--nonraid-homesNR /dev/sde1 /dev/sde2
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Test mode: Skipping archiving of volume group.
Extracting 1 image from data-nonraid/homesNR.
Are you sure you want to convert raid1 LV data-nonraid/homesNR to type linear losing all resilience? [y/n]: y
Accepted input: [y]
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
Internal error: Removing still active LV data-nonraid/homesNR_rmeta_0.

Het enige wat ik kan bedenken om het probleem te verhelpen, is de volume groep inactief te maken:

# umount /home/wbk/movies
# umount /home/wbk/music
# umount /home/wbk/pubNR
# vgchange -an data-nonraid
0 logical volume(s) in volume group "data-nonraid" now active

Ok, dat is niet de oplossing:

# lvconvert -tvm0 /dev/mapper/data--nonraid-homesNR /dev/sde1 /dev/sde2
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
data-nonraid/homesNR must be active to perform this operation

Veel gezocht, niets gevonden. De andere LV’s geven dezelfde fout, of ik nu de oude (sde) schijf opgeef om te verwijderen of de nieuwe (sdf).
Uiteindelijk de stoute schoenen aangetrokken, en niet als test gedaan. Meteen klaar, zonder error. Nu alleen nog bekijken wat er gebeurt is en uitzoeken wat het resultaat is:

lvconvert -vm0 /dev/mapper/data--nonraid-homesNR
Archiving volume group "data-nonraid" metadata (seqno 30). Extracting 1 image from data-nonraid/homesNR.
Are you sure you want to convert raid1 LV data-nonraid/homesNR to type linear losing all resilience? [y/n]: y
Accepted input: [y]
Loading table for data--nonraid-homesNR (253:33).
Loading table for data--nonraid-homesNR_rimage_0 (253:30).
Loading table for data--nonraid-homesNR_rimage_1 (253:32).
Suppressed data--nonraid-homesNR_rimage_1 (253:32) identical table reload.
Loading table for data--nonraid-homesNR_rmeta_0 (253:29).
Suppressed data--nonraid-homesNR_rmeta_0 (253:29) identical table reload.
Loading table for data--nonraid-homesNR_rmeta_0 (253:29).
Suppressed data--nonraid-homesNR_rmeta_0 (253:29) identical table reload.
Loading table for data--nonraid-homesNR_rmeta_1 (253:31).
Suppressed data--nonraid-homesNR_rmeta_1 (253:31) identical table reload.
Not monitoring data-nonraid/homesNR with libdevmapper-event-lvm2raid.so
Unmonitored LVM-qWbAa7jLmjPwVOFo54BePGqvqLAHDaf2luAq0nIxGTlOt0H0BznSULeI8m3K9eVJ for events
Suspending data--nonraid-homesNR (253:33) with device flush
Suspending data--nonraid-homesNR_rimage_1 (253:32) with device flush
Suspending data--nonraid-homesNR_rmeta_1 (253:31) with device flush
Suspending data--nonraid-homesNR_rimage_0 (253:30) with device flush
Suspending data--nonraid-homesNR_rmeta_0 (253:29) with device flush
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_1_extracted.
Loading table for data--nonraid-homesNR_rmeta_1 (253:31).
Suppressed data--nonraid-homesNR_rmeta_1 (253:31) identical table reload.
Renaming data--nonraid-homesNR_rmeta_1 (253:31) to data--nonraid-homesNR_rmeta_1_extracted
Resuming data--nonraid-homesNR_rmeta_1_extracted (253:31).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_1_extracted.
Loading table for data--nonraid-homesNR_rimage_1 (253:32).
Suppressed data--nonraid-homesNR_rimage_1 (253:32) identical table reload.
Renaming data--nonraid-homesNR_rimage_1 (253:32) to data--nonraid-homesNR_rimage_1_extracted
Resuming data--nonraid-homesNR_rimage_1_extracted (253:32).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
Loading table for data--nonraid-homesNR_rmeta_0 (253:29).
Suppressed data--nonraid-homesNR_rmeta_0 (253:29) identical table reload.
Resuming data--nonraid-homesNR_rmeta_0 (253:29).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
Resuming data--nonraid-homesNR_rimage_0 (253:30).
Resuming data--nonraid-homesNR (253:33).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_1_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_1_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
Removing data--nonraid-homesNR_rmeta_1_extracted (253:31)
Removing data--nonraid-homesNR_rimage_1_extracted (253:32)
Removing data--nonraid-homesNR_rmeta_0 (253:29)
Removing data--nonraid-homesNR_rimage_0 (253:30)
Loading table for data--nonraid-homesNR (253:33).
Suppressed data--nonraid-homesNR (253:33) identical table reload.
Suspending data--nonraid-homesNR (253:33) with device flush
Loading table for data--nonraid-homesNR (253:33).
Suppressed data--nonraid-homesNR (253:33) identical table reload.
Resuming data--nonraid-homesNR (253:33).
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 32).
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 32).
Logical volume data-nonraid/homesNR successfully converted.

Er is gebeurd wat de bedoeling was, al is het net andersom van wat ik van plan was. De oude PV heeft nu de homesNR-LV, ongespiegeld.

Voor deze LV is dat in orde, maar de andere LV’s van data-nonraid wil ik graag op de nieuwe PV /dev/sdf2 houden, in plaats van op de partities op /dev/sde.

Omdat ik niet weet hoe ik de ‘hoofd’ LV van een gespiegeld volume kan wisselen, moet ik het op een andere manier doen. Met lvconvert –splitmirror wordt de spiegel in twee functionerende LV’s gesplitst. De afgesplitste LV krijgt een nieuwe naam, de oorspronkelijke naam blijft behouden aan de bron-LV die de origine van de gespiegelde LV was. Weer net verkeerdom, wel minder destructief dan met het verwijderen van de spiegel van zonet.

Test-modus geeft weer een fout; misschien zitten er controles in het proces die niet goed kunnen lopen, omdat een eerdere stap in het proces als test uitgevoerd is. Dus op een rijtje: lvconvert –splitmirror, lvrename (oorspronkelijk naar oud), lvrename (nieuw naar oorspronkelijk)

# lvconvert -v --splitmirrors 1 --name pubNR2 /dev/data-nonraid/pubNR
Are you sure you want to split raid1 LV data-nonraid/pubNR losing all resilience? [y/n]: y
Accepted input: [y]
Losing all resilience for logical volume data-nonraid/pubNR.
Extracting 1 image from data-nonraid/pubNR.
Loading table for data--nonraid-pubNR (253:28).
Loading table for data--nonraid-pubNR_rimage_0 (253:25).
Loading table for data--nonraid-pubNR_rimage_1 (253:27).
Suppressed data--nonraid-pubNR_rimage_1 (253:27) identical table reload.
Loading table for data--nonraid-pubNR_rmeta_0 (253:24).
Suppressed data--nonraid-pubNR_rmeta_0 (253:24) identical table reload.
Loading table for data--nonraid-pubNR_rmeta_0 (253:24).
Suppressed data--nonraid-pubNR_rmeta_0 (253:24) identical table reload.
Loading table for data--nonraid-pubNR_rmeta_1 (253:26).
Suppressed data--nonraid-pubNR_rmeta_1 (253:26) identical table reload.
Not monitoring data-nonraid/pubNR with libdevmapper-event-lvm2raid.so
Unmonitored LVM-qWbAa7jLmjPwVOFo54BePGqvqLAHDaf2yBJS9YTOPHFu8zXGKtjSTe7pSBCQnSSO for events
Suspending data--nonraid-pubNR (253:28) with device flush
Suspending data--nonraid-pubNR_rimage_1 (253:27) with device flush
Suspending data--nonraid-pubNR_rmeta_1 (253:26) with device flush
Suspending data--nonraid-pubNR_rimage_0 (253:25) with device flush
Suspending data--nonraid-pubNR_rmeta_0 (253:24) with device flush
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR2.
Loading table for data--nonraid-pubNR_rimage_1 (253:27).
Suppressed data--nonraid-pubNR_rimage_1 (253:27) identical table reload.
Renaming data--nonraid-pubNR_rimage_1 (253:27) to data--nonraid-pubNR2
Resuming data--nonraid-pubNR2 (253:27).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_1_extracted.
Loading table for data--nonraid-pubNR_rmeta_1 (253:26).
Suppressed data--nonraid-pubNR_rmeta_1 (253:26) identical table reload.
Renaming data--nonraid-pubNR_rmeta_1 (253:26) to data--nonraid-pubNR_rmeta_1_extracted
Resuming data--nonraid-pubNR_rmeta_1_extracted (253:26).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_0.
Loading table for data--nonraid-pubNR_rmeta_0 (253:24).
Suppressed data--nonraid-pubNR_rmeta_0 (253:24) identical table reload.
Resuming data--nonraid-pubNR_rmeta_0 (253:24).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rimage_0.
Resuming data--nonraid-pubNR_rimage_0 (253:25).
Resuming data--nonraid-pubNR (253:28).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_1_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rimage_0.
Removing data--nonraid-pubNR_rmeta_1_extracted (253:26)
Removing data--nonraid-pubNR_rmeta_0 (253:24)
Removing data--nonraid-pubNR_rimage_0 (253:25)
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 35).
root@fractal:/var/log# lvs -ao+devices |grep pub
pubNR data-nonraid -wi-a----- 8.00g /dev/sde2(0)
pubNR2 data-nonraid -wi-a----- 8.00g /dev/sdf2(323587)
# lvrename /dev/data-nonraid/pubNR pubNR_oud
Renamed "pubNR" to "pubNR_oud" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/pubNR2 pubNR
Renamed "pubNR2" to "pubNR" in volume group "data-nonraid" 
# lvs -ao+devices |grep pub
pubNR data-nonraid -wi-a----- 8.00g /dev/sdf2(323587)
pubNR_oud data-nonraid -wi-a----- 8.00g /dev/sde2(0)

Aansluitend:

Voor de overige LV’s hetzelfde uitvoeren
de PV’s van volumegroepen data en data-nonraid splitsen naar nieuwe volumegroepen
de nieuwe volumegroepen samenvoegen

# lvconvert --splitmirrors 1 --name video2 /dev/data-nonraid/video
Are you sure you want to split raid1 LV data-nonraid/video losing all resilience? [y/n]: y
# lvconvert --splitmirrors 1 --name video2 /dev/data-nonraid/
homesNR muziekNR pubNR pubNR_oud video video2
# lvconvert --splitmirrors 1 --name muziekNR2 /dev/data-nonraid/muziekNR
Are you sure you want to split raid1 LV data-nonraid/muziekNR losing all resilience? [y/n]: y
# lvconvert --splitmirrors 1 --name muziekNR2 /dev/data-nonraid/
homesNR muziekNR muziekNR2 pubNR pubNR_oud video video2
# lvrename /dev/data-nonraid/video video_oud
Renamed "video" to "video_oud" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/video2 video
Renamed "video2" to "video" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/muziekNR muziekNR_oud
Renamed "muziekNR" to "muziekNR_oud" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/muziek2 muziekNR
Existing logical volume "muziek2" not found in volume group "data-nonraid"
# lvrename /dev/data-nonraid/muziekNR2 muziekNR
Renamed "muziekNR2" to "muziekNR" in volume group "data-nonraid"
# lvs -ao+devices |grep nonraid
homesNR data-nonraid -wi-a----- 90.00g /dev/sde1(262144)
homesNR data-nonraid -wi-a----- 90.00g /dev/sde2(84109)
muziekNR data-nonraid -wi-a----- 150.00g /dev/sdf2(1)
muziekNR_oud data-nonraid -wi-a----- 150.00g /dev/sde2(25600)
pubNR data-nonraid -wi-a----- 8.00g /dev/sdf2(323587)
pubNR_oud data-nonraid -wi-a----- 8.00g /dev/sde2(0)
video data-nonraid -wi-a----- <1.09t /dev/sdf2(38402)
video_oud data-nonraid -wi-a----- <1.09t /dev/sde1(0)
video_oud data-nonraid -wi-a----- <1.09t /dev/sde1(277504)
video_oud data-nonraid -wi-a----- <1.09t /dev/sde2(64000)

So far, so good. Nu voor VG ‘data’ hetzelfde riedeltje:

# lvs -ao+devices |grep aor
fotos data rwi-aor--- 2.68t 100.00 fotos_rimage_0(0),fotos_rimage_1(0)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md3(0)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md3(214575)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(119208)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md3(190735)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(0)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(36229)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(10629)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md2(0)
[fotos_rimage_1] data iwi-aor--- 2.68t /dev/sdf1(1)
[fotos_rmeta_0] data ewi-aor--- 4.00m /dev/md3(213295)
[fotos_rmeta_1] data ewi-aor--- 4.00m /dev/sdf1(0)
geluid data rwi-aor--- 16.56g 100.00 geluid_rimage_0(0),geluid_rimage_1(0)
[geluid_rimage_0] data iwi-aor--- 16.56g /dev/md3(202655)
[geluid_rimage_1] data iwi-aor--- 16.56g /dev/sdf1(703333)
[geluid_rmeta_0] data ewi-aor--- 4.00m /dev/md3(213296)
[geluid_rmeta_1] data ewi-aor--- 4.00m /dev/sdf1(703332)
# lvconvert --splitmirrors 1 --name fotos2 /dev/data/fotos
Are you sure you want to split raid1 LV data/fotos losing all resilience? [y/n]: y
root@fractal:/var/log# lvconvert --splitmirrors 1 --name geluid2 /dev/data/geluid
Are you sure you want to split raid1 LV data/geluid losing all resilience? [y/n]: y
root@fractal:/var/log# lvrename /dev/data/geluid geluid_oud
Renamed "geluid" to "geluid_oud" in volume group "data"
root@fractal:/var/log# lvrename /dev/data/geluid2 geluid
Renamed "geluid2" to "geluid" in volume group "data"
root@fractal:/var/log# lvrename /dev/data/fotos fotos_oud
Renamed "fotos" to "fotos_oud" in volume group "data"
root@fractal:/var/log# lvrename /dev/data/fotos fotos
/dev/data/fotos2 /dev/data/fotos_oud
root@fractal:/var/log# lvrename /dev/data/fotos2 fotos
Renamed "fotos2" to "fotos" in volume group "data"

Dat ziet er best goed uit. Op sdf staan nu twee volumegroepen met de logische volumes die ik daar wil hebben. Wat er nog moet gebeuren:

hernoem VG ‘data’ naar ‘data_oud’ met vgrename
splits de sdf1-LV’s af van VG data_oud naar nieuwe VG ‘data’
hernoem VG ‘data-nonraid’ naar data-nonraid_oud met vgrename
splits de sdf2-LV’s af van data-nonraid_oud en stop ze in bestaande VG ‘data’

# vgrename data
data data-nonraid
# vgrename data data_oud
Volume group "data" successfully renamed to "data_oud"
root@fractal:/var/log# vgrename data data_oud
data-nonraid data_oud
# vgrename data-nonraid data-nonraid_oud
Volume group "data-nonraid" successfully renamed to "data-nonraid_oud"
# vgsplit -tv data_oud data /dev/sdf1
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Checking for new volume group "data"
Checking for volume group "data_oud"
Test mode: Skipping archiving of volume group.
Logical volume data_oud/fotos must be inactive.
root@fractal:/var/log# vgchange -an data_oud
Logical volume data_oud/fotos_oud contains a filesystem in use.
Can't deactivate volume group "data_oud" with 2 open logical volume(s)
# umount /home/wbk/sounds
# umount /home/wbk/photos
# vgchange -an data_oud
0 logical volume(s) in volume group "data_oud" now active
# vgsplit -tv data_oud data /dev/sdf1
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Checking for new volume group "data"
Checking for volume group "data_oud"
Test mode: Skipping archiving of volume group.
Writing out updated volume groups
Test mode: Skipping archiving of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
New volume group "data" successfully split from "data_oud"
# vgsplit -v data_oud data /dev/sdf1
Checking for new volume group "data"
Checking for volume group "data_oud"
Archiving volume group "data_oud" metadata (seqno 35).
Writing out updated volume groups
Archiving volume group "data" metadata (seqno 0).
Creating volume group backup "/etc/lvm/backup/data" (seqno 1).
Creating volume group backup "/etc/lvm/backup/data_oud" (seqno 36).
Creating volume group backup "/etc/lvm/backup/data" (seqno 2).
New volume group "data" successfully split from "data_oud"
# mount |grep non
# vgchange -an data-nonraid_oud
0 logical volume(s) in volume group "data-nonraid_oud" now active
# vgsplit -v data-nonraid_oud data /dev/sdf2
Checking for new volume group "data"
Checking for volume group "data-nonraid_oud"
Archiving volume group "data-nonraid_oud" metadata (seqno 46).
Writing out updated volume groups
Archiving volume group "data" metadata (seqno 2).
Creating volume group backup "/etc/lvm/backup/data" (seqno 3).
Creating volume group backup "/etc/lvm/backup/data-nonraid_oud" (seqno 47).
Creating volume group backup "/etc/lvm/backup/data" (seqno 4).
Existing volume group "data" successfully split from "data-nonraid_oud"
# vgs
VG #PV #LV #SN Attr VSize VFree
boot 1 1 0 wz--n- 1.39g 1.21g
data 2 5 0 wz--n- <3.97t <28.27g
data-nonraid_oud 2 4 0 wz--n- 1.42t 92.98g
data_oud 3 2 0 wz--n- <2.73t 30.00g
homes 1 1 0 wz--n- <839.84g 744.71g
mailtemp 1 1 0 wz--n- 12.77g 0
system 1 6 0 wz--n- 83.81g 0

Alleen homesNR moet nog uit VG data-nonraid_oud naar de nieuwe schijf.

Alleen /dev/sde3 van de 3TB-schijf heeft nu nog data die niet op de nieuwe schijf staat. Er staat maar een VG (mailtemp) op, met een enkele LV (mail). De VG doet z’n naam eer aan, want die gaat nu weer tijdelijk naar /dev/sdf3 met pvmove, voordat ik de andere 6TB schijf inricht. Ondertussen is die LV al weer een tijd de mailstore van de mailserver op deze machine, ‘niets zo permanent als een tijdelijke oplossing’.

Er is nog 1,5TiB vrij van de nieuwe schijf. Voor de verschillende home-partities is nog een kleine 250TiB nodig; een deel daarvan zijn ROMs en ISO’s die eigenlijk in de data-VG geschoven moeten worden. Stappen daarvoor:

LV homesNR hernoemen naar rom met lvrename
Nieuwe partitie /dev/sdf3 op de nieuwe schijf met fdisk
Partitie als PV kenmerken met pvcreate
Partitie toekennen aan data-nonraid_oud met vgextend
LV rom spiegelen van /dev/sde[12] naar /dev/sdf3 met lvconvert -m1
Spiegeling splitsen met lvconvert –splitmirrors 1 –name rom2 /dev/data-nonraid_oud/rom

fdisk /dev/sdf
pvcreate /dev/sdf3
vgextend data-nonraid_oud /dev/sdf3
lvconvert -m 1 /dev/data-nonraid_oud/rom /dev/sdf3
lvrename /dev/data-nonraid_oud/rom rom2
lvconvert --splitmirrors 1 --name rom /dev/data-nonraid_oud/rom
umount /home/nonraid
vgchange -an data-nonraid_oud
vgsplit -tv data /dev/sdf3
root@fractal:/var/log# vgsplit data-nonraid_oud data /dev/sdf3
Existing volume group "data" successfully split from "data-nonraid_oud"
vgchange -ay data
vi /etc/fstab
mount -a
df -ht ext4
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/system-root 14G 1.2G 12G 9% /
/dev/mapper/system-usr 14G 14G 0 100% /usr
/dev/mapper/system-homesltd 28G 26G 108M 100% /home
/dev/mapper/boot-boot 167M 56M 98M 37% /boot
/dev/mapper/system-var 18G 15G 2.4G 86% /var
/dev/mapper/homes-wbk 94G 88G 940M 99% /home/wbk
/dev/mapper/system-varlog 6.3G 4.6G 1.5G 77% /var/log
/dev/mapper/system-varcache 2.9G 1.2G 1.6G 44% /var/cache
/dev/mapper/mailtemp-mail 13G 12G 310M 98% /var/vmail
/dev/mapper/data-fotos 2.7T 2.6T 2.8G 100% /home/wbk/photos
/dev/mapper/data-geluid 17G 11G 4.4G 72% /home/wbk/sounds
/dev/mapper/data-video 1.1T 1.1T 18G 99% /home/wbk/movies
/dev/mapper/data-rom 89G 84G 968M 99% /home/nonraid

Voor de home-directories is het lastig dat die van wbk gemount is terwijl ik bezig ben. Daarvoor dus uitloggen en su via een andere gebruiker.

Nog lastiger is het met de homesltd-LV. Die is onderdeel van de system-VG, waarvan alle extends gebruikt zijn. Er kan pas gespiegeld worden als er minimaal een PE beschikbaar is in de bron-VG.

Na een hoop puzzelen, lijkt de eenvoudigste manier om de LV voor de /var/cache-partitie weg te gooien.

——— // lange break offline, in rescue mode om system VG met root te migreren // ——–

–> hier plakken: aantekeningen uit rescue modus: migratie, bootproblemen na ontbrekende GPT BIOS boot-partitie voor GRUB

——- // hier weer online, met sechts 1 hdd in bedrijf, de 6T PMR-schijf // ———

SSD van 480G ingeplugd, met fdisk /dev/sdc partities toegevoegd:

8G swap
30G voor VG system
20G voor VG homes
50G voor VG data

root@fractal:~# fdisk -l /dev/sdc
Disk /dev/sdc: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B480C1C9-E7CB-D04D-BDCD-C797ED5F0512
Device Start End Sectors Size Type
/dev/sdc1 2048 16779263 16777216 8G Linux swap
/dev/sdc2 16779264 79693823 62914560 30G Linux LVM
/dev/sdc3 79693824 121636863 41943040 20G Linux LVM
/dev/sdc4 121636864 226494463 104857600 50G Linux LVM

Swap bruikbaar maken met makeswap /dev/sdc1 && swapon /dev/sdc1, ook aan /etc/fsctab toevoegen.

blkid /dev/sdc1
/dev/sdc1: UUID="f6eb076b-f587-4bf7-b307-9b75260a8bab" TYPE="swap" PARTUUID="d2a5a9b8-903f-4141-96d7-f931e93be283"

Partities beschikbaar maken voor LVM met pvcreate en toevoegen met vgextend:

root@fractal:~# pvcreate /dev/sdc2
Physical volume "/dev/sdc2" successfully created.
root@fractal:~# pvcreate /dev/sdc3
Physical volume "/dev/sdc3" successfully created.
root@fractal:~# pvcreate /dev/sdc4
Physical volume "/dev/sdc4" successfully created.
root@fractal:~# vgextend system /dev/sdc2
Volume group "system" successfully extended
root@fractal:~# vgextend homes /dev/sdc3
Volume group "homes" successfully extended
root@fractal:~# vgextend data /dev/sdc4
Volume group "data" successfully extended

Inrichten als cache volgens man 7 lvmcache. Om twee gescheiden apparaten in te zetten voor cache en cache-metadata (via een cachepool) is het makkelijker om ze tegelijkertijd beschikbaar te hebben. Daarvoor moet ik eerst wat schujven in de toewijzing van de SATA-poorten, toch liever off-line dus eerst de boel weer uitschakelen.

Opslagapparaten zitten er nu min of meer netjes in. De drie 2TB-schijven zitten er ‘draadloos’ in, de twee vrijgekomen SATA-poorten zijn vooralsnog op de DVD-schijvers aangesloten (er staan nog een paar spindels blanco DVD’s op foto’s te wachten, wie weet…).
De overige vier apparaten :

root@fractal:~# fdisk -l|grep 'Disk /dev/sd'
Disk /dev/sda: 967.5 MiB, 1014497280 bytes, 1981440 sectors
Disk /dev/sdb: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdc: 101.3 GiB, 108711411200 bytes, 212326975 sectors
Disk /dev/sdd: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sde: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors

Nu op de kleine SSD de partities voor LVM metadatacache aanleggen. Met een factor duizend kleiner dan het datacache gaat het over tientallen MB’s, niet echt de moeite. De LV’s voor het metadatacache moeten in dezelfde VG zitten als het datacache en de data zelf, maar naast de LV’s voor het metadatacache kunnen er natuurlijk meer LV’s op gezet worden, bijvoorbeeld voor databases (in data?) of configuratie- en thumnaildirectories in de home VG. Het idee van een bootpartitie op elke schijf heb ik, ondanks het lage opslagruimtegebruik, laten varen. Het komt maar zo zelden voor dat onvoorzien alle schijven uit het systeem zijn behalve ‘die ene’ schijf, en dan heeft een bootpartitie in z’n eentje ook niet veel zin meer. Bovendien heb ik de USB-stick met Debian-installer in de interne USB-poort geprikt. In geval van nood is daarop terug te vallen (zoals vandaag dus een paar keer aan de orde was).
Omdat cachetoewijzing op LV-niveau gedaan wordt, hoe ik de indeling van de kleine SSD bij nader inzien helemaal anders.

2GB swap
30G voor VG system
- enkele MB’s aan metadatacache voor partities niet op SSD
- 2GB voor root
- 20GB voor usr
- overige ruimte voor toekomstig gebrui
20G voor VG homes
- enkele MB’s aan metadatacache
- ruimte voor thumbnails in homedirs
- ruimte voor vaak geraakte bestanden in homedirs (browsercache, desktopcachebestanden)
- ruimte voor databases van bijvoorbeeld Digikam en Calibre
50G voor VG data
- enkele MB’s aan metadatacache
- ruimte voor databasebestanden van generieke processen
De overige ruimte ongepartitioneerd, als vrije ruimte voor de SSD

Eerst secure erase. Volgens horen zeggen, worden daarmee alle cellen leeggemaakt, en kan er voorlopig op volle snelheid geschreven worden.

// schrijf hier het stukje over ATA secure erase, verwijs naar Arch-wiki

# hdparm -I /dev/sdc|grep frozen
# dhparm --user-master u --security-set-pass 7yde7yk /dev/sdc
# hdparm -I /dev/sdc
# hdparm --user-master u --security-erase wankel78 /dev/sdc
# hdparm -I /dev/sdc

Cache inrichten

De volumegroepen, bestaande uit PV’s op de SMR-schijf zijn nu uitgebreid met PV’s uit telkens twee SSD’s. Nu kan ik datacache en metadatacache daarop inrichten. Voor de LV’s op de system-VG maak ik hier een notitie, de rest gaat op dezelfde manier. De hints in man 7 lvmcache zijn goed leesbaar, ik volg de stappen 1-op-1.

Voor de system-VG heb ik voor ogen:

raid 1 mirror voor root en usr over de HDD en de kleine SSD
schrijfcache van 8G voor die mirror
partities /var en /var/log op de HDD met 20G LVM-r/w-cache op de grote SSD, en 50M metadatacache op de kleine SSD.

# # creeer het datacache op de grote SSD
#lvcreate -vn sys_cache -L20G system /dev/sdd2
Archiving volume group "system" metadata (seqno 4). Creating logical volume sys_cache Creating volume group backup "/etc/lvm/backup/system" (seqno 5). Activating logical volume system/sys_cache. activation/volume_list configuration setting not defined: Checking only host tags for system/sys_cache. Creating system-sys_cache Loading table for system-sys_cache (254:13). Resuming system-sys_cache (254:13). Wiping known signatures on logical volume "system/sys_cache" Initializing 4.00 KiB of logical volume "system/sys_cache" with value 0.
Logical volume "sys_cache" created.
# # schakel het cache voor de LV's var en varlog in
# lvconvert --type cache --cachepool sys_cache system/var
WARNING: Converting system/sys_cache to cache pool's data volume with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert system/sys_cache? [y/n]: y
Converted system/sys_cache to cache pool.
Logical volume system/var is now cached.
# # LV var laten cachen:
# lvconvert --type cache --cachepool sys_cache system/var
WARNING: Converting system/sys_cache to cache pool's data volume with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert system/sys_cache? [y/n]: y
Converted system/sys_cache to cache pool.
Logical volume system/var is now cached.
# # LV varlog laten cachen
# lvconvert --type cache --cachepool sys_cache system/varlog
Cache pool sys_cache is already in use.
# # Dan maar weer ongedaan maken:
# lvconvert --splitcache system/sys_cache
Logical volume system/var is not cached and cache pool system/sys_cache is unused.
# lvconvert --splitcache system/sys_cache
Cannot find cache LV from system/sys_cache.
# lvremove /dev/system/sys_cache
Logical volume "sys_cache" successfully removed

Dat is niet wat ik had verwacht: een cachepool in een VG kan maar door een LV gebruikt worden, niet gedeeld. Omdat de bestanden op de LV’s in de system VG nog geen 50G in beslag nemen, gooi ik het helemaal over een andere boeg: alles in lvmraid 1.

De opdrachten voor het initieren van de RAID-LV’s wijken iets af van die hierboven, omdat het nu niet ter synchronisatie naar de ‘enige andere’ schijf in de VG is, maar naar ‘een van de meerdere PVs in de VG’, waarbij ik voor elke VG een specifieke SSD in gedachten heb. Daarnaast wil ik dat de HDD zo min mogelijk direct gebruikt wordt, om niet als een rem te werken. Dus: vooral lezen van de SSD’s, en bij schrijven niet wachten op de HDD. Voor de HDD betekend dat: ‘writemostly’, ‘raid_write_behind’.

# lvconvert -v --type raid1 -m1 /dev/system/root /dev/sdc2
Are you sure you want to convert linear LV system/root to raid1 with 2 images enhancing resilience? [y/n]: y
Accepted input: [y]
Archiving volume group "system" metadata (seqno 14).
Creating logical volume root_rmeta_0
Creating logical volume root_rmeta_1
Creating logical volume root_rimage_0
activation/volume_list configuration setting not defined: Checking only host tags for system/root_rmeta_0.
Creating system-root_rmeta_0
Loading table for system-root_rmeta_0 (254:13).
Resuming system-root_rmeta_0 (254:13).
activation/volume_list configuration setting not defined: Checking only host tags for system/root_rmeta_1.
Creating system-root_rmeta_1
Loading table for system-root_rmeta_1 (254:14).
Resuming system-root_rmeta_1 (254:14).
Wiping metadata area system/root_rmeta_0.
Wiping known signatures on logical volume "system/root_rmeta_0"
Initializing 512 B of logical volume "system/root_rmeta_0" with value 0.
Wiping metadata area system/root_rmeta_1.
Wiping known signatures on logical volume "system/root_rmeta_1"
Initializing 512 B of logical volume "system/root_rmeta_1" with value 0.
Removing system-root_rmeta_0 (254:13)
Removing system-root_rmeta_1 (254:14)
Creating logical volume root_rimage_0
Creating system-root_rmeta_0
Loading table for system-root_rmeta_0 (254:13).
Resuming system-root_rmeta_0 (254:13).
Creating system-root_rimage_0
Loading table for system-root_rimage_0 (254:14).
Resuming system-root_rimage_0 (254:14).
Creating system-root_rmeta_1
Loading table for system-root_rmeta_1 (254:15).
Resuming system-root_rmeta_1 (254:15).
Creating system-root_rimage_1
Loading table for system-root_rimage_1 (254:16).
Resuming system-root_rimage_1 (254:16).
Loading table for system-root (254:0).
Suspending system-root (254:0) with device flush
Loading table for system-root_rmeta_0 (254:13).
Suppressed system-root_rmeta_0 (254:13) identical table reload.
Loading table for system-root_rimage_0 (254:14).
Suppressed system-root_rimage_0 (254:14) identical table reload.
Loading table for system-root_rmeta_1 (254:15).
Suppressed system-root_rmeta_1 (254:15) identical table reload.
Loading table for system-root_rimage_1 (254:16).
Suppressed system-root_rimage_1 (254:16) identical table reload.
Resuming system-root (254:0).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 16).
Creating volume group backup "/etc/lvm/backup/system" (seqno 17).
Logical volume system/root successfully converted.
# # aansluitend kijken hoever de sync is
# lvs /dev/system/root
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root system rwi-aor--- 5.00g 21.46

Daarna de sync voor var, usr en varlog aanzetten:

# lvconvert --type raid1 -m1 /dev/system/var /dev/sdc2
Are you sure you want to convert linear LV system/var to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvconvert --type raid1 -m1 /dev/system/usr /dev/sdd2
Are you sure you want to convert linear LV system/usr to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume system/usr successfully converted. 
root@fractal:~# iostat -hd 3 /dev/sd[cd]2 /dev/sda6
Linux 4.9.0-0.bpo.11-amd64 (fractal) 08/11/20 x86_64 (4 CPU)
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
182.67 89.1M 8.5k 267.4M 25.5k sda6
99.33 0.0k 48.1M 0.0k 144.2M sdc2
83.67 0.0k 41.3M 0.0k 123.9M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
161.67 78.6M 13.3k 235.7M 40.0k sda6
97.67 0.0k 47.4M 0.0k 142.2M sdc2
64.33 0.0k 31.0M 0.0k 92.9M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
199.34 100.4M 0.5k 302.1M 1.5k sda6
99.67 0.0k 49.8M 0.0k 149.9M sdc2
100.00 0.0k 50.6M 0.0k 152.2M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
224.00 93.5M 13.3k 280.6M 40.0k sda6
33.33 0.0k 14.9M 0.0k 44.7M sdc2
191.00 0.0k 78.9M 0.0k 236.6M sdd2
# lvconvert --type raid1 -m1 /dev/system/varlog /dev/sdd2
Are you sure you want to convert linear LV system/varlog to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume system/varlog successfully converted.
root@fractal:~# iostat -hd 3 /dev/sd[cd]2 /dev/sda6
Linux 4.9.0-0.bpo.11-amd64 (fractal) 08/11/20 x86_64 (4 CPU)
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
205.00 85.0M 21.0k 255.1M 63.0k sda6
2.33 0.0k 12.0k 0.0k 36.0k sdc2
204.00 0.0k 85.3M 0.0k 255.8M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
269.33 100.0M 12.5k 300.1M 37.5k sda6
1.67 0.0k 11.5k 0.0k 34.5k sdc2
268.00 0.0k 100.0M 0.0k 300.1M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
251.00 95.6M 7.0k 286.9M 21.0k sda6
2.33 0.0k 5.7k 0.0k 17.0k sdc2
250.33 0.0k 95.6M 0.0k 286.9M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
315.33 100.4M 12.5k 301.3M 37.5k sda6
2.67 0.0k 12.5k 0.0k 37.5k sdc2
314.00 0.0k 100.4M 0.0k 301.3M sdd2

RAID-conversie is nu klaar voor alle system-LV’s, nu afstemmen om vooral de SSD’s aan te spreken om zo min mogelijk last van de HDD te hebben.

Optie ‘writemostly’: de genoemde PV wordt ontzien bij leesacties, niet bij schrijven. Daardoor krijgt die drive minder I/O-acties voor z’n kiezen. Met het instellen van ‘writemostly’, komt de optie ‘writebehind’ beschikbaar.

Optie ‘writebehind’: voor een PV waarop ‘writemostly’ actief is, kan ingesteld worden hoeveel schrijfacties de PV achter mag lopen.

Stel dat de SSD vijf keer zo snel is als de HDD, en ze respectievelijk 50 en 5 schrijfacties per seconde kunnen doen. In het reguliere geval zijn de schrijfacties synchroon (write-through): een schrijfactie wordt pas als gereed gemarkeerd, als het opslagmedium ‘OK’ teruggeeft.
Zolang er op het systeem minder dan 5 schijfacties per seconde plaatsvinden, is er geen probleem. Als dat aantal stijgt, is er wel een probleem: doordat de schrijfacties synchroon gebeuren, moet het systeem wachten op iedere schrijfactie die boven die 5 per seconde uitgaat. Als er vanaf de CPU in een seconde 40 schrijfacties komen, betekent het dat die CPU vervolgens 7 seconden extra moet wachten voordat er een OK terug is op alle schrijfacties.
In dat voorbeeld is er wat betreft de SSD geen probleem: die presteert op 80%, en kan de schrijfacties makkelijk aan. Hier komt de ‘writebehind’ optie om de hoek kijken: door die, in het voorbeeld, op 45 te zetten, kan de CPU de SSD in de hoogste versnelling laten werken, voor een seconde in ieder geval.
Zodra het aantal achtergebleven schrijfacties (45 in dit geval) overschreden wordt, wisselt de hele LV naar synchroon schrijven. Als er dus 4 seconden lang, 50 schrijfacties per seconden gedaan zouden worden, zou na de eerste seconde de LV omslaan naar synchroon. De overige 150 schrijfacties geven pas OK nadat zowel de SSD als de HDD klaar zijn. De SSD kan gelijke tred met de CPU houden, maar de HDD heeft veel meer tijd nodig. Het hele systeem wordt voor ruim een halve minuut opgehouden, totdat de HDD alle 200 acties verwerkt heeft.

Het inschakelen van ‘writemostly’ -v geeft veel meer output dan ik op basis van -t verwacht had, maar is zo gedaan:

# lvchange -tv --writemostly /dev/sda6 /dev/system/*
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Test mode: Skipping archiving of volume group.
Logical volume system/root changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Logical volume system/usr changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Logical volume system/var changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Logical volume system/varlog changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
# lvchange -v --writemostly /dev/sda6 /dev/system/*
Archiving volume group "system" metadata (seqno 26).
Logical volume system/root changed.
Loading table for system-root_rimage_1 (254:16).
Suppressed system-root_rimage_1 (254:16) identical table reload.
Loading table for system-root_rmeta_1 (254:15).
Suppressed system-root_rmeta_1 (254:15) identical table reload.
Loading table for system-root_rimage_0 (254:14).
Suppressed system-root_rimage_0 (254:14) identical table reload.
Loading table for system-root_rmeta_0 (254:13).
Suppressed system-root_rmeta_0 (254:13) identical table reload.
Loading table for system-root (254:0).
Not monitoring system/root with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Suspending system-root (254:0) with device flush
Suspending system-root_rimage_1 (254:16) with device flush
Suspending system-root_rmeta_1 (254:15) with device flush
Suspending system-root_rimage_0 (254:14) with device flush
Suspending system-root_rmeta_0 (254:13) with device flush
Loading table for system-root_rimage_1 (254:16).
Suppressed system-root_rimage_1 (254:16) identical table reload.
Loading table for system-root_rmeta_1 (254:15).
Suppressed system-root_rmeta_1 (254:15) identical table reload.
Loading table for system-root_rimage_0 (254:14).
Suppressed system-root_rimage_0 (254:14) identical table reload.
Loading table for system-root_rmeta_0 (254:13).
Suppressed system-root_rmeta_0 (254:13) identical table reload.
Resuming system-root_rimage_1 (254:16).
Resuming system-root_rmeta_1 (254:15).
Resuming system-root_rimage_0 (254:14).
Resuming system-root_rmeta_0 (254:13).
Resuming system-root (254:0).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 27).
Creating volume group backup "/etc/lvm/backup/system" (seqno 27).
Creating volume group backup "/etc/lvm/backup/system" (seqno 27).
Logical volume system/usr changed.
Loading table for system-usr_rimage_1 (254:24).
Suppressed system-usr_rimage_1 (254:24) identical table reload.
Loading table for system-usr_rmeta_1 (254:23).
Suppressed system-usr_rmeta_1 (254:23) identical table reload.
Loading table for system-usr_rimage_0 (254:22).
Suppressed system-usr_rimage_0 (254:22) identical table reload.
Loading table for system-usr_rmeta_0 (254:21).
Suppressed system-usr_rmeta_0 (254:21) identical table reload.
Loading table for system-usr (254:1).
Not monitoring system/usr with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events
Suspending system-usr (254:1) with device flush
Suspending system-usr_rimage_1 (254:24) with device flush
Suspending system-usr_rmeta_1 (254:23) with device flush
Suspending system-usr_rimage_0 (254:22) with device flush
Suspending system-usr_rmeta_0 (254:21) with device flush
Loading table for system-usr_rimage_1 (254:24).
Suppressed system-usr_rimage_1 (254:24) identical table reload.
Loading table for system-usr_rmeta_1 (254:23).
Suppressed system-usr_rmeta_1 (254:23) identical table reload.
Loading table for system-usr_rimage_0 (254:22).
Suppressed system-usr_rimage_0 (254:22) identical table reload.
Loading table for system-usr_rmeta_0 (254:21).
Suppressed system-usr_rmeta_0 (254:21) identical table reload.
Resuming system-usr_rimage_1 (254:24).
Resuming system-usr_rmeta_1 (254:23).
Resuming system-usr_rimage_0 (254:22).
Resuming system-usr_rmeta_0 (254:21).
Resuming system-usr (254:1).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 28).
Creating volume group backup "/etc/lvm/backup/system" (seqno 28).
Creating volume group backup "/etc/lvm/backup/system" (seqno 28).
Logical volume system/var changed.
Loading table for system-var_rimage_1 (254:20).
Suppressed system-var_rimage_1 (254:20) identical table reload.
Loading table for system-var_rmeta_1 (254:19).
Suppressed system-var_rmeta_1 (254:19) identical table reload.
Loading table for system-var_rimage_0 (254:18).
Suppressed system-var_rimage_0 (254:18) identical table reload.
Loading table for system-var_rmeta_0 (254:17).
Suppressed system-var_rmeta_0 (254:17) identical table reload.
Loading table for system-var (254:3).
Not monitoring system/var with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKmSXVL0bFAndQH51ED0RIy91IgYM1DaRD for events
Suspending system-var (254:3) with device flush
Suspending system-var_rimage_1 (254:20) with device flush
Suspending system-var_rmeta_1 (254:19) with device flush
Suspending system-var_rimage_0 (254:18) with device flush
Suspending system-var_rmeta_0 (254:17) with device flush
Loading table for system-var_rimage_1 (254:20).
Suppressed system-var_rimage_1 (254:20) identical table reload.
Loading table for system-var_rmeta_1 (254:19).
Suppressed system-var_rmeta_1 (254:19) identical table reload.
Loading table for system-var_rimage_0 (254:18).
Suppressed system-var_rimage_0 (254:18) identical table reload.
Loading table for system-var_rmeta_0 (254:17).
Suppressed system-var_rmeta_0 (254:17) identical table reload.
Resuming system-var_rimage_1 (254:20).
Resuming system-var_rmeta_1 (254:19).
Resuming system-var_rimage_0 (254:18).
Resuming system-var_rmeta_0 (254:17).
Resuming system-var (254:3).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKmSXVL0bFAndQH51ED0RIy91IgYM1DaRD for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 29).
Creating volume group backup "/etc/lvm/backup/system" (seqno 29).
Creating volume group backup "/etc/lvm/backup/system" (seqno 29).
Logical volume system/varlog changed.
Loading table for system-varlog_rimage_1 (254:28).
Suppressed system-varlog_rimage_1 (254:28) identical table reload.
Loading table for system-varlog_rmeta_1 (254:27).
Suppressed system-varlog_rmeta_1 (254:27) identical table reload.
Loading table for system-varlog_rimage_0 (254:26).
Suppressed system-varlog_rimage_0 (254:26) identical table reload.
Loading table for system-varlog_rmeta_0 (254:25).
Suppressed system-varlog_rmeta_0 (254:25) identical table reload.
Loading table for system-varlog (254:4).
Not monitoring system/varlog with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGK3TNMGJWyr6sO9HNm13KjBhRF1m4eqOcc for events
Suspending system-varlog (254:4) with device flush
Suspending system-varlog_rimage_1 (254:28) with device flush
Suspending system-varlog_rmeta_1 (254:27) with device flush
Suspending system-varlog_rimage_0 (254:26) with device flush
Suspending system-varlog_rmeta_0 (254:25) with device flush
Loading table for system-varlog_rimage_1 (254:28).
Suppressed system-varlog_rimage_1 (254:28) identical table reload.
Loading table for system-varlog_rmeta_1 (254:27).
Suppressed system-varlog_rmeta_1 (254:27) identical table reload.
Loading table for system-varlog_rimage_0 (254:26).
Suppressed system-varlog_rimage_0 (254:26) identical table reload.
Loading table for system-varlog_rmeta_0 (254:25).
Suppressed system-varlog_rmeta_0 (254:25) identical table reload.
Resuming system-varlog_rimage_1 (254:28).
Resuming system-varlog_rmeta_1 (254:27).
Resuming system-varlog_rimage_0 (254:26).
Resuming system-varlog_rmeta_0 (254:25).
Resuming system-varlog (254:4).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGK3TNMGJWyr6sO9HNm13KjBhRF1m4eqOcc for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 30).
Creating volume group backup "/etc/lvm/backup/system" (seqno 30).
Creating volume group backup "/etc/lvm/backup/system" (seqno 30).
#

Het instellen van writebehind geeft netzoveel output bij -v, zonder valt het mee:

# lvchange --raidwritebehind 255 /dev/system/root
Logical volume system/root changed.
# lvchange --raidwritebehind 255 /dev/system/usr
Logical volume system/usr changed.
# lvchange --raidwritebehind 255 /dev/system/var
Logical volume system/var changed.
# lvchange --raidwritebehind 255 /dev/system/varlog
Logical volume system/varlog changed.

De waarde van 255 heb ik vrij willekeurig gekozen. Voor draaiende schijven kunnen de prestaties inzakken tot 3 schrijfacties per seconde, maar dat is bij een schrijfpatroon dat totaal willekeurig is (4k random reads, dus ~10kB/s). Om bij sequentieel schrijven aan 100MB/s te komen met blokken van een paar MB, moet de schijf zo’n 50 bewerkingen per seconde (IOPS) halen.
Op die twee aannames gebaseerd, zit je met 255 op 5 seconden wachten als er grote bestanden geschreven worden, of een paar minuten met honderden kleine bestandjes op willekeurige plaatsen op de schijf.

Ik kijk het eerst een tijdje op deze manier aan. De LV’s zijn nu gespiegeld, ik kan ze eventueel weer loskoppelen en de SSD-helft van de spiegel vervolgens als cache inzetten.

Voor de overige VG’s houd ik nog wel een cachingmechanisme aan.

# # eerst voor /home/wbk/
# lvcreate -vn cache_wbk -L18G homes /dev/sdd3
Logical volume "cache_wbk" created.
lvcreate -vn cache_meta_wbk -L100M homes /dev/sdc3
Logical volume "cache_meta_wbk" created.
# vconvert -v --type cache --cachepool cache_wbk --poolmetadata cache_meta_wbk /dev/homes/wbk
Setting chunk size to 64.00 KiB.
Preferred pool metadata size 100.00 MiB.
Pool metadata extents 25 chunk_size 128
WARNING: Converting homes/cache_wbk and homes/cache_meta_wbk to cache pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert homes/cache_wbk and homes/cache_meta_wbk? [y/n]: y
Converted homes/cache_wbk and homes/cache_meta_wbk to cache pool.
Logical volume homes/wbk is now cached.
# # daarna voor de overige homedirectories op /home/
# lvcreate -vn cache_homes -L7G homes /dev/sdc3
Logical volume "cache_homes" created.
#lvcreate -vn cache_meta_homes -L100M homes /dev/sdd3
Logical volume "cache_meta_homes" created.
# lvconvert --type cache --cachepool cache_homes --poolmetadata cache_meta_homes /dev/homes/home
WARNING: Converting homes/cache_homes and homes/cache_meta_homes to cache pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert homes/cache_homes and homes/cache_meta_homes? [y/n]: y
Converted homes/cache_homes and homes/cache_meta_homes to cache pool.
Logical volume homes/home is now cached.

Voor de data-VG is het dubbel jammer dat het cache per LV toegewezen moet worden. De verhouding is al schever dan bij de andere twee VG’s en er zijn meer LV’s tevreden te houden. Aan de andere kant is het vooral de foto-LV waar wat gebeurt, en de pub-LV waar random geschreven zou kunnen worden. Ik ga voor een cache op de foto-LV. Als de prestaties van een van de overige LV’s erg tegenvallen, schuif ik alsnog met de toewijzing.

# lvcreate -n cache_fotos -L48G data /dev/sdd4
Logical volume "cache_fotos" created.
# lvcreate -n cache_meta_fotos -L100M data /dev/sdc4
Logical volume "cache_meta_fotos" created.
# lvconvert --type cache --cachepool cache_fotos --poolmetadata cache_meta_fotos /dev/data/fotos
WARNING: Converting data/cache_fotos and data/cache_meta_fotos to cache pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/cache_fotos and data/cache_meta_fotos? [y/n]: y
Converted data/cache_fotos and data/cache_meta_fotos to cache pool.
Logical volume data/fotos is now cached.

Losse eindjes

De basis staat er nu wel. Losse eindjes die zo bij me opkomen:

De bestanden die van de kleine SSD afkomen en aangekoppeld zijn op /home/ssdata, met databases van Calibre (SQLite) en Digikam (in MySQL). Die mogen weer terug naar een nieuw te maken LV in VG data.
De bestanden die nog op de 6TB WD-schijf staan. Ongeveer 2,5TB aan backups, HDD-images en overige ‘bestanden die ergens geparkeerd moesten worden’. Uitzoeken en kijken wat er nog op de SMR-schijf gearchiveerd kan worden.
Als de 6TB schijf leeg is, die indelen op zo’n manier dat daar de komende ‘live’ data op terechtkomt. Misschien /home/wbk/ en de verschillende system-LV’s daarheen verplaatsen
Functionaliteit om mee te experimenteren:
- lvmthin: thin provisioning
- lvmdo: dataoptimalisatie, compressie en deduplicatie
Inrichting overig
- data-LV’s aankoppelen onder /home/ en via bind-mount beschikbaar maken in ieders homedirectory, via die weg ook in Nextcloud
- OverlayFS, om ieders wijzigingen aan de data-LV’s in de eigen homedirectory op te slaan

Eerst de data van /home/ssdata verplaatsen:

# lvcreate -n ssdata -L40G data /dev/sdc4
# mkfs.ext4 /dev/data/ssdata
# mount /dev/data/ssdata /mnt/p1
# service mysql stop
# cp -vr --preserve /home/ssdata/mysql/ /mnt/p1/
# cp -vr --preserve /home/ssdata/calibre/ /mnt/p1/
# # aankoppelpunt wijzigen 
# vi /etc/fstab
# umount /home/ssdata
# umount /mnt/p1
# mount /dev/mapper/data-ssdata
# mount|grep ssd
/dev/mapper/data-ssdata on /home/ssdata type ext4 (rw,noatime,data=ordered)
# service mysql start

De 2,2TiB data bestaan voor 1,6TiB uit een backup van foto’s van twee jaar geleden. Een nieuwe backup kan nu naar de, ondertussen vrije, 3TB schijf. De resterende <600GiB kan op het staartje van de SMR-schijf:

# fdisk /dev/sdb
# # --> n, enter, enter, +1.1T enter, t 31 enter, w enter
# pvcreate /dev/sdb9
# vgextend data /dev/sdb9
# # het logische volume niet willekeurig (en misschien deels op de SSD plaatsen): stuur lvcreate met /dev/sdb9 
# lvcreate -n archief -L 800G /dev/data /dev/sdb9
# mkfs.ext4 /dev/mapper/data-archief
# vi /etc/fstab 
# cat /etc/fstab|grep arch
/dev/mapper/data-archief /home/data/archief ext4 noatime,noexec,auto 0 2
# mount -a 
# cp -vr --preserve /mnt/p1/backup/* /home/data/archief/
# iostat -hd 3 /dev/sdb9 /dev/sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
153.33 0.0k 102.5M 0.0k 307.6M sdb9
362.67 90.7M 0.0k 272.0M 0.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
164.33 0.0k 114.6M 0.0k 343.9M sdb9
472.00 117.5M 0.0k 352.4M 0.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device 80.67 0.0k 55.4M 0.0k 166.1M sdb9
262.00 65.5M 0.0k 196.5M 0.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
141.00 0.0k 94.0M 0.0k 282.0M sdb9
324.00 81.0M 5.3k 243.0M 16.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device

Huishoudelijk: disk repartitioneren tot:

Device     Start     End          Sectors Size Type
/dev/sde1      2048   4294969343 4294967296 2T Linux LVM
/dev/sde2 4294969344  6442452991 2147483648 1T Linux LVM
/dev/sde3 6442452992 10737420287 4294967296 2T Linux LVM
/dev/sde4 10737420288 10947135487 209715200 100G Linux LVM 
          10947135488 11721045134 773909647 369G  free
# # grappig... 
# pvcreate /dev/sde[1234]
WARNING: atari signature detected on /dev/sde3 at offset 454. Wipe it? [y/n]:
Wiping atari signature on /dev/sde3.

Toewijzing aan VG’s gaf een opvallende waarschuwing:

# pvcreate /dev/sde[1234]
WARNING: atari signature detected on /dev/sde3 at offset 454. Wipe it? [y/n]:
Wiping atari signature on /dev/sde3.

Verder niets noemenswaardigs bij het toewijzen:

# vgextend data /dev/sde1
Volume group "data" successfully extended
# vgextend homes /dev/sde2
Volume group "homes" successfully extended
# vgcreate infra /dev/sde3
Volume group "infra" successfully created
# vgextend system /dev/sde4
Volume group "system" successfully extended

Tussentijdse conclusies en overwegingen

Het systeem draait nu zo’n week met /home/ op de SMR-schijf. Het valt me mee wat er het aan vertraging veroorzaakt, maar ik denk dat een groot deel van de bruikbaarheid aan het SSD-cache te danken is.

Voorafgaand aan en net na het configureren van cache, duurde het tientallen seconden voordat bijvoorbeeld Dolphin geopend werd; in sommige gevallen ben ik weggelopen bij de machine om m’n tijd nuttiger te besteden.

Nu het cache een paar dagen actief is, start Dolphin niet in een flits, maar is er wel op te wachten; in minder dan twee seconden is het programma bruikbaar.

Gigabytes aan gegevens verplaatsen van de ene partitie op de SMR-schijf naar de andere is te overzien, maar gaat ook niet vliegensvlug. Als het om enkel schrijven naar de schijf gaat, zag ik vaak snelheden van 80-90MB/s, met uitschieters naar 120MB/s. Dat is bij het initieel vullen van de schijf, waarbij er geen lees-schrijf-schijf actie nodig is. Bij het verplaatsen nu de schijf voller zit, moet er zowel gelezen als geschreven worden, en mogelijk moet bij het schrijven data herschreven worden.

Ik denk dat ik de inrichting van de schijven nog wat ga aanpassen bij het daadwerkelijk in gebruik nemen van de PMR-schijf. Video’s, en muziek/foto’s in mindere mate, zijn grote blokken data die sequentieel geschreven worden en weinig daarna vrij statisch zijn. SMR-schijven lenen zich daar prima voor.

Home-directories, met documenten die telkens aangepast worden, configuratiebestanden, tijdelijke bestanden en downloads, zijn in dat opzicht veel dynamischer. Een PMR-schijf is daarvoor meer geschikt.

Het ‘begin met een lege schijf en schrijf die van begin tot eind vol’ is, ook met meerdere LV’s, goed te doen dankzij lvmthin: daarbij worden juist de fysieke datablokken pas aangesproken op het moment dat ze nodig zijn, en dus in volgorde van leeg naar vol, zonder gaten. De resulterende LV kan wel gefragmenteerd raken, maar dat is in brokken van meerdere MB’s omdat de bestanden in dat patroon geschreven worden.

De PMR-schijf blijft daarmee beschikbaar voor home-directories en ander dynamischer gebruik.

Een ander gevolg van die indeling is dat de toewijzing van SSD-cache meer geconcentreerd kan worden op de PMR-schijf: het bulk aan data op de SMR-schijf wordt zo laagfrequent aangesproken, dat caching daarvan weinig nut heeft. Een schijfcache is nog te overwegen, bovenop de 128/256MB disk-cache en het PMR-cache op de SMR-schijf. Dat is vooral voor de foto-LV interessant, zodat SD-kaartjes op volle snelheid gelezen kunnen worden.

Eerst de system-VG van PMR naar SMR, respectievelijk op sdb en sde.

# lvconvert -m1 /dev/system/root /dev/sde4 
# lvconvert -m1 /dev/system/varlog /dev/sde4
# lvconvert -m1 /dev/system/var /dev/sde4
# lvconvert -m1 /dev/system/usr /dev/sde4
# pvs /dev/sde4
PV VG Fmt Attr PSize PFree
/dev/sde4 system lvm2 a-- <100.00g <100.00g

Raar… Er is niets geschreven naar /dev/sde3; met iostat was er ook nauwelijks verkeer te zien. Misschien is het mechanisme in de war door het cache wat er tussen zit. Morgen opnieuw proberen, nadat het cache uitgeschakeld is.

“De volgende dag…”

Het cache zorgt er inderdaad voor dat het spiegelen anders loopt dan ik verwacht. LV root is een virtuele LV op basis van de feitelijke data (op sdb6) en het cache (op sdc2). Dat volume is omgezet naar type=raid1, maar er is geen fysieke drager aangehangen omdat die op een lager niveau ligt. Als ik de LV op het lagere niveau probeer te spiegelen, krijg ik als foutmelding:

# lvconvert -tm1 /dev/system/root_rimage_0 /dev/sde4
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Operation not permitted on hidden LV system/root_rimage_0.

Twee opties, naast het erbij laten:

Caching ongedaan maken, daarna LV kopieren via lvm-raid en spiegeling vervolgens ongedaan maken, caching weer activeren;
de system-LV’s gebruiken voor lvm-thin met external origin (waarschijnlijk hetzelfde probleem, dat loopt ook via lvconvert;
of nietsdoen

De eerste optie is even irritant, maar zonder cache disablen zit het vast in het huidige stramien. Gelukkig gaat het verwijderen van cache even moeiteloos als het inschakelen ervan. Bij het controleren van de inrichting met

# lvs -a -o name,segtype,devices 
root raid1 root_rimage_0(0),root_rimage_1(0)
[root_rimage_0] linear /dev/sdb6(1)
[root_rimage_1] linear /dev/sdc2(1)
[root_rmeta_0] linear /dev/sdb6(10343)
[root_rmeta_1] linear /dev/sdc2(0)

… realiseerde ik me hoe de vork in de steel zit. De system-LV’s zijn, zoals een paar pagina’s naar boven beschreven, al ingericht als lvmraid. Mijn actie om een enkelvoudige spiegel aan te leggen, slaat nergens op als er al een spiegel is. Aanleggen van een extra spiegel, dus -m2, heeft wel effect:

# lvconvert -m2 /dev/system/root /dev/sde4
Are you sure you want to convert raid1 LV system/root to 3 images enhancing resilience? [y/n]: y
Logical volume system/root successfully converted.
root@fractal:~# lvs -a /dev/system/root
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root system rwi-aor--- 5.00g 16.70
iostat -hd 5 /dev/sdb6 /dev/sde4 /dev/sdc2 /dev/sdd2
Linux 4.9.0-0.bpo.11-amd64 (fractal) 21/11/20 x86_64 (4 CPU)
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device 
9.00 0.0k 88.8k 0.0k 444.0k sdb6
602.80 85.9M 78.3k 429.2M 391.5k sdc2
1.40 0.0k 10.4k 0.0k 52.0k sdd2
594.60 0.0k 86.2M 0.0k 431.2M sde4
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device 
8.40 51.2k 332.3k 256.0k 1.6M sdb6
588.20 85.4M 328.9k 426.9M 1.6M sdc2
3.40 102.4k 3.4k 512.0k 17.0k sdd2
579.00 25.6k 84.9M 128.0k 424.4M sde4 
# lvconvert -m2 /dev/system/varlog
Are you sure you want to convert raid1 LV system/varlog to 3 images enhancing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvconvert -m2 /dev/system/var /dev/sde4
Are you sure you want to convert raid1 LV system/var to 3 images enhancing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvconvert -m2 /dev/system/usr /dev/sde4
Are you sure you want to convert raid1 LV system/usr to 3 images enhancing resilience? [y/n]: y
Logical volume system/usr successfully converted.

Nu weer een LV eruithalen, namelijk de spiegel op /dev/sdb6. De voorbeelden in de manpages zijn net iets te summier om te herleiden welke PV nu uit RAID gehaald wordt, eerder verwijderde ik juist de verkeerde. De documentatie van Red Hat geeft hetzelfde voorbeeld, maar omdat erbij verteld wordt wat het gevolg is (in plaats van alleen wat de wens is) kan ik dat wel plaatsen. Zo gelezen, zo gedaan:

# lvconvert -m1 system/varlog /dev/sdb6
Are you sure you want to convert raid1 LV system/varlog to 2 images reducing resilience? [y/n]: yes
Logical volume system/varlog successfully converted.
# lvs -a /dev/system/varlog
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
varlog system rwi-aor--- <6.52g 100.00 
# lvs -a /dev/system/varlog -o devices
Devices
varlog_rimage_0(0),varlog_rimage_1(0)
# lvs -a /dev/system/varlog_rimage_0 -o devices
Devices
/dev/sdd2(4374)
# lvs -a /dev/system/varlog_rimage_1 -o devices
Devices
/dev/sde4(1282)

Ja, het juiste PV is verdwenen.

Dezelfde truc voor LV’s root, usr en var. Daarna usr uitbreiden, en kijken of ik var uitbreid of subdirectories op een losse partitie/LV zet (zoals voorheen /var/cache).

# lvs -a /dev/system/var_rimage_0 -o devices
Devices
/dev/sdb6(5655)
# lvs -a /dev/system/var_rimage_1 -o devices
Devices
/dev/sdc2(1282)
# lvs -a /dev/system/var_rimage_2 -o devices
Devices
/dev/sde4(2951)
# lvconvert -m1 system/var /dev/sdb6
Are you sure you want to convert raid1 LV system/var to 2 images reducing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvs -a /dev/system/var_rimage_2 -o devices
Failed to find logical volume "system/var_rimage_2"
# lvs -a /dev/system/var_rimage_1 -o devices
Devices
/dev/sde4(2951)
# lvs -a /dev/system/var_rimage_0 -o devices
Devices
/dev/sdc2(1282) 
# lvconvert -m1 system/usr /dev/sdb6
Are you sure you want to convert raid1 LV system/usr to 2 images reducing resilience? [y/n]: yes
Logical volume system/usr successfully converted.
# lvconvert -m1 system/root /dev/sdb6
Are you sure you want to convert raid1 LV system/root to 2 images reducing resilience? [y/n]: y
Logical volume system/root successfully converted.
# lvextend -vtr /dev/system/usr -L+3G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Extending 2 mirror images.
Executing: /sbin/fsadm --dry-run --verbose check /dev/system/usr
fsadm: "ext4" filesystem found on "/dev/mapper/system-usr".
fsadm: Skipping filesystem check for device "/dev/mapper/system-usr" as the filesystem is mounted on /usr
/sbin/fsadm failed: 3
Test mode: Skipping archiving of volume group.
Extending logical volume system/usr to <20.08 GiB Size of logical volume system/usr changed from <17.08 GiB (4372 extents) to <20.08 GiB (5140 extents). Test mode: Skipping backup of volume group. Logical volume system/usr successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/system/usr 21053440K fsadm: "ext4" filesystem found on "/dev/mapper/system-usr". fsadm: Device "/dev/mapper/system-usr" size is 18337497088 bytes fsadm: Parsing tune2fs -l "/dev/mapper/system-usr" fsadm: Resizing filesystem on device "/dev/mapper/system-usr" to 21558722560 bytes (3690496 -> 5263360 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/system-usr 5263360
# lvextend -vr /dev/system/usr -L+3G
Extending 2 mirror images.
Executing: /sbin/fsadm --verbose check /dev/system/usr
fsadm: "ext4" filesystem found on "/dev/mapper/system-usr".
fsadm: Skipping filesystem check for device "/dev/mapper/system-usr" as the filesystem is mounted on /usr
/sbin/fsadm failed: 3
Archiving volume group "system" metadata (seqno 61).
Extending logical volume system/usr to <20.08 GiB Size of logical volume system/usr changed from <17.08 GiB (4372 extents) to <20.08 GiB (5140 extents). Loading table for system-usr_rimage_1 (254:47). Resuming system-usr_rimage_1 (254:47). Loading table for system-usr_rmeta_1 (254:46). Suppressed system-usr_rmeta_1 (254:46) identical table reload. Loading table for system-usr_rimage_0 (254:8). Resuming system-usr_rimage_0 (254:8). Loading table for system-usr_rmeta_0 (254:7). Suppressed system-usr_rmeta_0 (254:7) identical table reload. Loading table for system-usr (254:9). Not monitoring system/usr with libdevmapper-event-lvm2raid.so Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events Suspending system-usr (254:9) with device flush Suspending system-usr_rimage_1 (254:47) with device flush Suspending system-usr_rmeta_1 (254:46) with device flush Suspending system-usr_rimage_0 (254:8) with device flush Suspending system-usr_rmeta_0 (254:7) with device flush Loading table for system-usr_rimage_1 (254:47). Suppressed system-usr_rimage_1 (254:47) identical table reload. Loading table for system-usr_rmeta_1 (254:46). Suppressed system-usr_rmeta_1 (254:46) identical table reload. Loading table for system-usr_rimage_0 (254:8). Suppressed system-usr_rimage_0 (254:8) identical table reload. Loading table for system-usr_rmeta_0 (254:7). Suppressed system-usr_rmeta_0 (254:7) identical table reload. Resuming system-usr_rimage_1 (254:47). Resuming system-usr_rmeta_1 (254:46). Resuming system-usr_rimage_0 (254:8). Resuming system-usr_rmeta_0 (254:7). Resuming system-usr (254:9). Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events Creating volume group backup "/etc/lvm/backup/system" (seqno 62). Logical volume system/usr successfully resized. Executing: /sbin/fsadm --verbose resize /dev/system/usr 21053440K fsadm: "ext4" filesystem found on "/dev/mapper/system-usr". fsadm: Device "/dev/mapper/system-usr" size is 21558722560 bytes fsadm: Parsing tune2fs -l "/dev/mapper/system-usr" fsadm: Resizing filesystem on device "/dev/mapper/system-usr" to 21558722560 bytes (3690496 -> 5263360 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/system-usr 5263360
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/system-usr is mounted on /usr; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mapper/system-usr is now 5263360 (4k) blocks long.

Bij het uitbreiden van de root-LV, was ik nogal verbaasd dat de gebruikte ruimte afnam van 85% naar nog geen 30%, met 4G beschikbaar in plaats van 300M. Ik kwam erachter dat er stiekum nog een hoop ruimte in de LV zat, die niet in het bestandssysteem opgenomen was:

# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 2.0G 1.6G 289M 85% /
# lvextend -vr /dev/system/root -L+1G
Extending 2 mirror images.
Executing: /sbin/fsadm --verbose check /dev/system/root
fsadm: "ext4" filesystem found on "/dev/mapper/system-root".
fsadm: Skipping filesystem check for device "/dev/mapper/system-root" as the filesystem is mounted on /
/sbin/fsadm failed: 3
Archiving volume group "system" metadata (seqno 63).
Extending logical volume system/root to 6.00 GiB
Size of logical volume system/root changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
Loading table for system-root_rimage_1 (254:41).
Resuming system-root_rimage_1 (254:41).
Loading table for system-root_rmeta_1 (254:40).
Suppressed system-root_rmeta_1 (254:40) identical table reload.
Loading table for system-root_rimage_0 (254:3).
Resuming system-root_rimage_0 (254:3).
Loading table for system-root_rmeta_0 (254:2).
Suppressed system-root_rmeta_0 (254:2) identical table reload.
Loading table for system-root (254:4).
Not monitoring system/root with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Suspending system-root (254:4) with device flush
Suspending system-root_rimage_1 (254:41) with device flush
Suspending system-root_rmeta_1 (254:40) with device flush
Suspending system-root_rimage_0 (254:3) with device flush
Suspending system-root_rmeta_0 (254:2) with device flush
Loading table for system-root_rimage_1 (254:41).
Suppressed system-root_rimage_1 (254:41) identical table reload.
Loading table for system-root_rmeta_1 (254:40).
Suppressed system-root_rmeta_1 (254:40) identical table reload.
Loading table for system-root_rimage_0 (254:3).
Suppressed system-root_rimage_0 (254:3) identical table reload.
Loading table for system-root_rmeta_0 (254:2).
Suppressed system-root_rmeta_0 (254:2) identical table reload.
Resuming system-root_rimage_1 (254:41).
Resuming system-root_rmeta_1 (254:40).
Resuming system-root_rimage_0 (254:3).
Resuming system-root_rmeta_0 (254:2).
Resuming system-root (254:4).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 64).
Logical volume system/root successfully resized.
Executing: /sbin/fsadm --verbose resize /dev/system/root 6291456K
fsadm: "ext4" filesystem found on "/dev/mapper/system-root".
fsadm: Device "/dev/mapper/system-root" size is 6442450944 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/system-root"
fsadm: Resizing filesystem on device "/dev/mapper/system-root" to 6442450944 bytes (563154 -> 1572864 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/system-root 1572864
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/system-root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mapper/system-root is now 1572864 (4k) blocks long.
# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 5.8G 1.6G 4.0G 29% /

‘So be it’; als er nog eens per ongeluk een groot bestand in / valt, stort de boel niet meteen in wegens ruimtegebrek. Tot slot van deze exercitie de nu ongebruikte PV sdb6 weghalen uit VG system:

# vgreduce -va system
Archiving volume group "system" metadata (seqno 62).
Removing "/dev/sdb6" from volume group "system"
Creating volume group backup "/etc/lvm/backup/system" (seqno 63).
Removed "/dev/sdb6" from volume group "system"
Physical volume "/dev/sdd2" still in use
Physical volume "/dev/sdc2" still in use
Physical volume "/dev/sde4" still in use

so far… so good.

Data VG fatsoeneren

Het begint er al aardig op te lijken, met de system-VG op een schijfcombinate waar ik me geen zorgen over extreme prestatie-dips hoef te maken en vrije schijfruimte beschikbaar is.

De data- en home-LV’s zijn nog niet in de vorm die ik voor ogen heb. Ik denk dat een deel van het doel wat ik voor ogen had met AUFS/OverlayFS bereikt kan worden met ‘lvmthin with external origin’.

Print this entry

18 april 2021

Schijf vervangen, LVM volume group uitbreiden

Met de vorige uitbreidingen (lvextend) waren de laatste restjes vrije ruimte in de data-volumegroep benut. Op de system-volumegroep was nog wel iets ruimte, maar dat hield ook niet over.

De SSD van 480GB is daarom vervangen door eentje van 960GB. De oude van 480GB wordt cache in de desktop/NAS/mediaserver, die wordt misschien als tweede node in een Proxmox configuratie opgenomen.

Eerst de schijf verwisselen. De laptop heeft ruimte voor twee SATA-apparaten, maar een van de aansluitingen is defect. Kopieren leek me het handigste aan de USB3-poorten van de desktop.

De beide SSD’s heb ik aangesloten via SATA<>USB3-adapters, maar bij het aansluiten op de USB3-poorten op de desktop kwamen foutmeldingen, bij een test op USB2 niet. Daarom via de USB2-poorten aangesloten. Wel langzamer, maar 480Gb/s zou in een datarate van zo’n 35-45MB/s moeten vertalen, acceptabel voor ~450GB aan data.

pv > /dev/sdh > /dev/sdg

De datarate viel me tegen, fluctuerend tussen 1 en 6 MB/s, met uitschieters naar boven en beneden. De volgende dag, na ruim 12 uur, was krap 10% gekopieerd, met als prognose nog ruim een dag. Dat was een stuk slechter dan ik had verwacht, ook met USB2.

Daarom toch intern aangesloten. Boot met beide schijven werkte niet: er was al voldoende gekopieerd om twee schijven met identieke LVM-configuratie te hebben, dat gaf problemen.

Dus: boot zonder de beide SSD’s, daarna hotplug aan de interne SATA.

Vervolgens gaf het kopieren een totaal ander beeld, bij aanvang ruim 250MB/s. Ik meen dat de SATA-aansluitingen op het moederbord SATA2 zijn, dus met een maximum bandbreedte van 300MB/s. Met de gemeten snelheid zou het een half uur duren om de volledige schijf te kopieren.

Uiteindelijk is de performance nog aardig ingezakt, tot rond 15MB/s en dips rond 5MB/s, maar na 2 uur was de kopieerslag klaar.

Op de server heb ik nog een LVM-partitie aan de SSD toegevoegd. Het uitbreiden van de volumegroep heb ik nog niet gedaan, omdat op de server een volumegroep bestaat met dezelfde naam.

Na het inbouwen van de nieuwe SSD in de laptop, boot die zonder problemen. Aan de slag!

LVM-partitie toevoegen aan de volume groep

Er zijn twee volumegroepen, en aan elk daarvan is een fysiek volume (partitie) toegekend:

root@linhovo:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 system lvm2 a-- 51.47g 27.89g
/dev/sda3 data lvm2 a-- 347.65g 136.00m

De volumegroepen zijn net zo groot als de som van de toegewezen partities:

root@linhovo:~# vgs
VG #PV #LV #SN Attr VSize VFree
data 1 2 0 wz--n- 347.65g 136.00m
system 1 4 0 wz--n- 51.47g 27.89g

Met vgextend kan volumegroep uitgebreid worden met een partitie. Er zijn zes partities:

root@linhovo:~# fdisk -l
Disk /dev/sda: 894.3 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: Intenso SSD SATA
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EA98124F-2230-4671-A4B6-C197DAB72AA2

Device        Start          End    Sectors   Size Type
/dev/sda1 1024000       36863999   35840000  17.1G Linux swap
/dev/sda2 36864000     144818175  107954176  51.5G Linux LVM
/dev/sda3 247685120    976773119  729088000 347.7G Linux LVM
/dev/sda4 2048            352255     350208   171M Linux filesystem
/dev/sda5 352256          546815     194560    95M BIOS boot
/dev/sda6 976773120   1710776319  734003200   350G Linux LVM

Partition table entries are not in disk order.

De laatste partitie, op /dev/sda6, is nieuw. Die wordt aan de data-volumegroep toegevoegd:

root@linhovo:~# vgextend -tv data /dev/sda6
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Wiping signatures on new PV /dev/sda6.
Set up physical volume for "/dev/sda6" with 734003200 available sectors.
Zeroing start of device /dev/sda6.
Writing physical volume data to disk "/dev/sda6".
Physical volume "/dev/sda6" successfully created.
Test mode: Skipping archiving of volume group.
Adding physical volume '/dev/sda6' to volume group 'data'
Failed to find cached info for PV /dev/sda6.
PV /dev/sda6 cannot be added to VG data.

… Failed to find cached info for PV /dev/sda6, cannot be added. Ik weet nog niet waar de gecachte info vandaan zou moeten komen, maar ik had verwacht een pv..-opdracht te moeten geven voordat ik een vg…-opdracht kon geven.

Met pv-tab-tab krijg ik een veelbelovend lijstje:

root@linhovo:~# pv
pvchange pvck pvcreate pvdisplay pvmove pvremove pvresize pvs pvscan
root@linhovo:~# pvcreate --help
(hulp)
root@linhovo:~# pvcreate /dev/sda6
Physical volume "/dev/sda6" successfully created.

Daarna kan de volumegroep uitgebreid worden met het gedefinieerde fysieke volume:

root@linhovo:~# vgextend -tv data /dev/sda6
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Wiping signatures on new PV /dev/sda6.
Test mode: Skipping archiving of volume group.
Adding physical volume '/dev/sda6' to volume group 'data'
Volume group "data" will be extended by 1 new physical volumes
Test mode: Skipping backup of volume group.
Volume group "data" successfully extended

Het resultaat:

root@linhovo:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 system lvm2 a-- 51.47g 27.89g
/dev/sda3 data lvm2 a-- 347.65g 136.00m
/dev/sda6 lvm2 --- 350.00g 350.00g

Ongebruikte LVM-ruimte op sda6. Geen volume toegewezen. Dat nu met vgextend:

root@linhovo:~# vgextend -tv data /dev/sda6
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Wiping signatures on new PV /dev/sda6.
Test mode: Skipping archiving of volume group.
Adding physical volume ‘/dev/sda6’ to volume group ‘data’
Volume group “data” will be extended by 1 new physical volumes
Test mode: Skipping backup of volume group.
Volume group “data” successfully extended

Nu voor het echie, zonder -t:

root@linhovo:~# vgextend -v data /dev/sda6
Wiping signatures on new PV /dev/sda6.
Archiving volume group “data” metadata (seqno 6).
Adding physical volume ‘/dev/sda6’ to volume group ‘data’
Volume group “data” will be extended by 1 new physical volumes
Creating volume group backup “/etc/lvm/backup/data” (seqno 7).
Volume group “data” successfully extended

En ter controle:
root@linhovo:~# vgs
VG #PV #LV #SN Attr VSize VFree
data 2 2 0 wz–n- <697.65g <350.13g
system 1 4 0 wz–n- 51.47g 27.89g

Nu het logische volume uitbreiden, eerst de huidige vrije ruimte ter vergelijking:

root@linhovo:~# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 6.5G 142M 6.0G 3% /
/dev/mapper/system-usr ext4 9.4G 7.2G 1.7G 82% /usr
/dev/mapper/data-home ext4 58G 17G 39G 31% /home
/dev/mapper/system-var ext4 6.4G 972M 5.1G 16% /var
/dev/mapper/data-linh ext4 284G 264G 5.9G 98% /home/linh
/dev/mapper/system-log ext4 922M 30M 829M 4% /var/log

De uit te breiden partitie is /home/linh, die dus eerst loskoppelen:

root@linhovo:~# umount /dev/mapper/data-linh
umount: /home/linh: target is busy.
root@linhovo:~# lsof |grep /home/linh
(lijstje)

Met htop filteren op user = linh, en de programma’s afsluiten met k. De grafische interfase op de laptop staat al uit, met service sddm stop, dus er kan geen gebruikersdata verloren gaan.

Nog eens loskoppelen:

root@linhovo:~# umount /dev/mapper/data-linh
root@linhovo:~# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 6.5G 142M 6.0G 3% /
/dev/mapper/system-usr ext4 9.4G 7.2G 1.7G 82% /usr
/dev/mapper/data-home ext4 58G 17G 39G 31% /home
/dev/mapper/system-var ext4 6.4G 972M 5.1G 16% /var
/dev/mapper/system-log ext4 922M 30M 829M 4% /var/log
root@linhovo:~# mount|grep mapper
/dev/mapper/system-root on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/system-usr on /usr type ext4 (rw,relatime)
/dev/mapper/data-home on /home type ext4 (rw,relatime)
/dev/mapper/system-var on /var type ext4 (rw,relatime)
/dev/mapper/system-log on /var/log type ext4 (rw,relatime)

Nu het logische volume uitbreiden, eerst in test-modus:

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda6 -tvrL +330G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/fsadm –dry-run –verbose check /dev/data/linh
fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”.
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-linh
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <618.58 GiB Size of logical volume data/linh changed from <288.58 GiB (73876 extents) to <618.58 GiB (158356 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm –dry-run –verbose resize /dev/data/linh 648626176K fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”. fsadm: Device “/dev/mapper/data-linh” size is 309858402304 bytes fsadm: Parsing tune2fs -l “/dev/mapper/data-linh” fsadm: Resizing filesystem on device “/dev/mapper/data-linh” to 664193204224 bytes (75649024 -> 162156544 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 162156544

Dan weer in het echt:

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda6 -vrL +330G
Executing: /sbin/fsadm –verbose check /dev/data/linh
fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”.
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-linh
fsck from util-linux 2.33.1
linh: 79452/18915328 files (6.3% non-contiguous), 70513450/75649024 blocks
Archiving volume group “data” metadata (seqno 7).
Extending logical volume data/linh to <618.58 GiB Size of logical volume data/linh changed from <288.58 GiB (73876 extents) to <618.58 GiB (158356 extents). Loading table for data-linh (254:3). Suspending data-linh (254:3) with device flush Resuming data-linh (254:3). Creating volume group backup “/etc/lvm/backup/data” (seqno 8). Logical volume data/linh successfully resized. Executing: /sbin/fsadm –verbose resize /dev/data/linh 648626176K fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”. fsadm: Device “/dev/mapper/data-linh” size is 664193204224 bytes fsadm: Parsing tune2fs -l “/dev/mapper/data-linh” fsadm: Resizing filesystem on device “/dev/mapper/data-linh” to 664193204224 bytes (75649024 -> 162156544 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-linh 162156544
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-linh to 162156544 (4k) blocks.
The filesystem on /dev/mapper/data-linh is now 162156544 (4k) blocks long.

In test-modus duurde het nauwelijks een seconde, de feitelijke transactie duurde vijf keer zo lang. Dus na een seconde of vijf:

root@linhovo:~# fdisk -l /dev/mapper/data-linh
Disk /dev/mapper/data-linh: 618.6 GiB, 664193204224 bytes, 1297252352 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Bestandssysteem aankoppelen….

root@linhovo:~# mount /dev/mapper/data-linh

… en de grootte verifieren:

root@linhovo:~# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 6.5G 142M 6.0G 3% /
/dev/mapper/system-usr ext4 9.4G 7.2G 1.7G 82% /usr
/dev/mapper/data-home ext4 58G 17G 39G 31% /home
/dev/mapper/system-var ext4 6.4G 972M 5.1G 16% /var
/dev/mapper/system-log ext4 922M 30M 829M 4% /var/log
/dev/mapper/data-linh ext4 608G 264G 315G 46% /home/linh

De vrije ruimte is toegenomen met 310G, er zit dus zo’n 8% overhead in LVM. Van 98% gevuld zonet naar 46% na het uitbreiden van de partitie.

Grafische interface weer aanzetten…

root@linhovo:~# service sddm start

en na inloggen de ruimte in de browser controleren:

Print this entry

3 maart 2021

LVM: thin snapshot with external origin

LVM kan ’thin’ beschikbaar gesteld (’thin provisioning’) worden. Daarbij ligt slechts een beperkte hoeveelheid fysieke ruimte ten grondslag aan logische ruimte van willekeurige grootte. Pas als er daadwerkelijk data weggeschreven wordt, wordt de benodigde hoeveelheid fysieke ruimte toegewezen.

Thin provisioning kun je combineren met een read-only snapshot. Het logische volume heeft alle inhoud van het snapshot; wijzigingen daarop en nieuwe data worden in de gegevensruimte van het logische volume weggeschreven.

Een thin-LV waarbij op die manier een snapshot ingezet wordt, heet ‘thin LV with an external origin’.

Ik wil alle data-LV’s op de trage SMR-schijf read-only maken, en schrijven naar de snellere reguliere CMR-schijf. Ik moet trouwens zeggen: het systeem draait ondertussen al weken op de SMR-schijf met SSD-caching, zonder dat ik er veel van merk. Dan speelt vast mee dat alle partities tegen 100% bezet zijn, en ik zodoende bijna niets schrijf naar de schijf.

Als eerste test de partitie met video’s.

# lvs data/video
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
video data -wi-ao---- <1.09t

In de eerste instantie dacht ik dat een placeholder voor een thin pool aangemaakt zou worden bij het converteren, dat is niet het geval:

# lvconvert -tv --type thin --thinpool data/datalvpool --originname videoRO data/video
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Thin pool videopool not found.

Aanmaken van de pool gaat goed in de test-modus:

# lvcreate -tv --type thin-pool -L 1T -n datalvpool data
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/modprobe dm-thin-pool
Setting chunk size to 512.00 KiB.
Thin pool volume with chunk size 512.00 KiB can address at most 126.50 TiB of data.
Enabling pool zeroing on default.
WARNING: Pool zeroing and 512.00 KiB large chunk size slows down thin provisioning.
WARNING: Consider disabling zeroing (-Zn) or using smaller chunk size (<512.00 KiB).
Preferred pool metadata size 128.00 MiB.
Making pool datalvpool in VG data using segtype thin-pool
Test mode: Skipping archiving of volume group.
Creating logical volume datalvpool
Creating logical volume datalvpool_tmeta
Creating logical volume datalvpool_tdata
Test mode: Skipping backup of volume group.
Test mode: Skipping activation, zeroing and signature wiping.
Logical volume "datalvpool" created.

Aansluitend ‘voor het echie’, ook OK:

# lvcreate -v --type thin-pool -L 1T -n datalvpool data
Setting chunk size to 512.00 KiB.
Thin pool volume with chunk size 512.00 KiB can address at most 126.50 TiB of data.
Enabling pool zeroing on default.
WARNING: Pool zeroing and 512.00 KiB large chunk size slows down thin provisioning.
WARNING: Consider disabling zeroing (-Zn) or using smaller chunk size (<512.00 KiB).
Preferred pool metadata size 128.00 MiB.
Making pool datalvpool in VG data using segtype thin-pool
Archiving volume group "data" metadata (seqno 17).
Creating logical volume datalvpool
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpool.
Creating data-datalvpool
Loading table for data-datalvpool (254:40).
Resuming data-datalvpool (254:40).
Initializing 4.00 KiB of logical volume "data/datalvpool" with value 0.
Removing data-datalvpool (254:40)
Creating logical volume datalvpool_tmeta
Creating logical volume datalvpool_tdata
Creating volume group backup "/etc/lvm/backup/data" (seqno 19).
Activating logical volume data/datalvpool.
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpool.
Creating data-datalvpool_tmeta
Loading table for data-datalvpool_tmeta (254:40).
Resuming data-datalvpool_tmeta (254:40).
Creating data-datalvpool_tdata
Loading table for data-datalvpool_tdata (254:41).
Resuming data-datalvpool_tdata (254:41).
Creating data-datalvpool
Loading table for data-datalvpool (254:42).
Resuming data-datalvpool (254:42).
Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPGIvNwVRhR7YfVIYFwuZ3xiY1JNCe9fNw-tpool for events
Logical volume "datalvpool" created.

Testmodus van de conversie van video-LV-regulier naar video-LV-thin met extern RO-snapshot geeft een onverwachte waarschuwing:

# lvconvert -tv --type thin --thinpool data/datalvpool --originname videoRO data/video
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Test mode: Skipping archiving of volume group.
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpool.
Deactivating public thin pool data/datalvpool.
Creating logical volume videoRO
WARNING: Sum of all thin volume sizes (<1.09 TiB) exceeds the size of thin pool data/datalvpool (1.00 TiB).
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
Test mode: Skipping backup of volume group.
Test mode: Skipping activation, zeroing and signature wiping.
Logical volume "videoRO" created.
Setting logical volume "data/videoRO" read-only.
Test mode: Skipping backup of volume group.

Wat me opvalt: ‘you have not turned on protection against thin pools running out of space’. Ik dacht dat er ‘sensible’ defaults gemaakt zouden zijn, zodat een overprovisioned (meer beloofd dan beschikbaar) thin LV ‘vanzelf’ goed zou gaan. De waarschuwing over 100% hint dat ik moet aangeven dat bijvoorbeeld bij 90% ruimte in gebruik, er 5% toegevoegd wordt aan datalvpool, uit VG data.

Ik realiseer me nu ook dat ik niet heb aangegeven dat datalvpool aangemaakt moet worden op de juiste schijf, dus dat doe ik opnieuw. Data op de ‘WD Red’ sde, metadata op SSD sdb. Het blijkt vanzelf al bijna goedgegaan:

# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
datalvpool data twi-a-tz-- 1.00t 0.00 10.42
[datalvpool_tdata] data Twi-ao---- 1.00t
[datalvpool_tmeta] data ewi-ao---- 128.00m
[lvol0_pmspare] data ewi------- 128.00m
# # VG, LV en PV: 
# vgs -a -o vg_name,lv_name,devices data|grep lv
data datalvpool datalvpool_tdata(0)
data [lvol0_pmspare] /dev/sda1(707573)
data [datalvpool_tmeta] /dev/sdd4(12288)
data [datalvpool_tdata] /dev/sde1(0)

Een actieve LV kan niet verwijderd worden, dus eerst deactiveren, daarna verwijderen:

# lvchange -an data/datalvpool
# lvremove data/datalvpool
Logical volume "datalvpool" successfully removed

Nu opnieuw aanmaken, met de PV’s die ik in gedachten heb. Daarvoor moeten de onderliggende LV’s (meta en data) voor de thin LV separaat aangemaakt worden en geconverteerd naar een thin LV. Er is vast een alles-in-een commando voor, maar die heb ik niet zo snel herkend.

# pvs /dev/sde*
Failed to find device for physical volume "/dev/sde".
PV VG Fmt Attr PSize PFree
/dev/sde1 data lvm2 a-- <2.00t <2.00t
/dev/sde2 homes lvm2 a-- <1024.00g <1024.00g
/dev/sde3 infra lvm2 a-- <2.00t <2.00t
/dev/sde4 system lvm2 a-- <100.00g 49.07g
# vgs data
VG #PV #LV #SN Attr VSize VFree
data 7 8 0 wz--n- 7.31t <2.42t
# pvs /dev/sdb*
Failed to find device for physical volume "/dev/sdb".
Failed to find physical volume "/dev/sdb1".
PV VG Fmt Attr PSize PFree
/dev/sdb2 system lvm2 a-- <30.00g <5.68g
/dev/sdb3 homes lvm2 a-- <20.00g <12.90g
/dev/sdb4 data lvm2 a-- <48.00g <7.90g
# lvcreate -n datalvpooltdata -L 1t data /dev/sde1
Logical volume "datalvpooltdata" created.
# lvcreate -n datalvpooltmeta -L 255m data /dev/sdb4
Rounding up size to full physical extent 256.00 MiB
Logical volume "datalvpooltmeta" created.
# lvconvert -tv --type thin-pool --poolmetadata data/datalvpooltmeta data/datalvpooltdata
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Setting chunk size 256.00 KiB.
Thin pool volume with chunk size 256.00 KiB can address at most 63.25 TiB of data.
Enabling pool zeroing on default.
Preferred pool metadata size 256.00 MiB.
Pool metadata extents 64 chunk_size 512
WARNING: Converting data/datalvpooltdata and data/datalvpooltmeta to thin pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/datalvpooltdata and data/datalvpooltmeta? [y/n]: y
Accepted input: [y]
Test mode: Skipping archiving of volume group.
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpooltmeta.
Initializing 4.00 KiB of logical volume "data/datalvpooltmeta" with value 0.
Creating logical volume datalvpooltdata
Activation of logical volume data/datalvpooltdata is prohibited while logical volume data/datalvpooltdata_tmeta is active.
Failed to activate pool logical volume data/datalvpooltdata.
Test mode: Skipping backup of volume group.
# lvchange -an data/datalvpooltdata_tmeta
Failed to find logical volume "data/datalvpooltdata_tmeta"
# lvchange -an data/datalvpooltdata
# lvchange -an data/datalvpooltmeta
# lvconvert -tv --type thin-pool --poolmetadata data/datalvpooltmeta data/datalvpooltdata
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Setting chunk size 256.00 KiB.
Thin pool volume with chunk size 256.00 KiB can address at most 63.25 TiB of data.
Enabling pool zeroing on default.
Preferred pool metadata size 256.00 MiB.
Pool metadata extents 64 chunk_size 512
WARNING: Converting data/datalvpooltdata and data/datalvpooltmeta to thin pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/datalvpooltdata and data/datalvpooltmeta? [y/n]: y
Accepted input: [y]
Test mode: Skipping archiving of volume group.
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpooltmeta.
Volume "data/datalvpooltmeta" is not active locally (volume_list activation filter?).
Aborting. Failed to wipe metadata lv.
# lvchange -ay data/datalvpooltmeta
# lvconvert -tv --type thin-pool --poolmetadata data/datalvpooltmeta data/datalvpooltdata
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Setting chunk size 256.00 KiB.
Thin pool volume with chunk size 256.00 KiB can address at most 63.25 TiB of data.
Enabling pool zeroing on default.
Preferred pool metadata size 256.00 MiB.
Pool metadata extents 64 chunk_size 512
WARNING: Converting data/datalvpooltdata and data/datalvpooltmeta to thin pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/datalvpooltdata and data/datalvpooltmeta? [y/n]: y
Accepted input: [y]
Test mode: Skipping archiving of volume group.
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpooltmeta.
Initializing 4.00 KiB of logical volume "data/datalvpooltmeta" with value 0.
Creating logical volume datalvpooltdata
Test mode: Skipping backup of volume group.
Converted data/datalvpooltdata and data/datalvpooltmeta to thin pool.

Anders dan in de documentatie, klaagt lvconvert in testmodus dat de LV actief is. Na ze allebei inactief gemaakt te hebben, blijkt meta juist wel actief te moeten zijn en enkel data moet inactief zijn. Ik vroeg me af of dat enkel voor de testmodus gold, en heb de data-LV ook weer actief gemaakt voor ik de conversie uitvoerde. Het blijkt een verschil tusses de test- en werkelijke modus te zijn, want nu wordt het wel uitgevoerd. Voorafgaand aan de conversie en aansluitend daaraan doe ik een opsomming van de LV’s om het verschil te bekijken:

# lvs -a data
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
datalvpooltdata data -wi------- 1.00t
datalvpooltmeta data -wi-a----- 256.00m
[lvol0_pmspare] data ewi------- 128.00m
# lvchange -ay data/datalvpooltdata
# lvconvert -v --type thin-pool --poolmetadata data/datalvpooltmeta data/datalvpooltdata
Setting chunk size 256.00 KiB.
Thin pool volume with chunk size 256.00 KiB can address at most 63.25 TiB of data.
Enabling pool zeroing on default.
Preferred pool metadata size 256.00 MiB.
Pool metadata extents 64 chunk_size 512
WARNING: Converting data/datalvpooltdata and data/datalvpooltmeta to thin pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/datalvpooltdata and data/datalvpooltmeta? [y/n]: y
Accepted input: [y]
Removing data-datalvpooltmeta (254:40)
Archiving volume group "data" metadata (seqno 22).
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpooltmeta.
Creating data-datalvpooltmeta
Loading table for data-datalvpooltmeta (254:40).
Resuming data-datalvpooltmeta (254:40).
Initializing 4.00 KiB of logical volume "data/datalvpooltmeta" with value 0.
Removing data-datalvpooltmeta (254:40)
Removing data-datalvpooltdata (254:41)
Creating logical volume datalvpooltdata
activation/volume_list configuration setting not defined: Checking only host tags for data/datalvpooltdata.
Creating data-datalvpooltdata_tmeta
Loading table for data-datalvpooltdata_tmeta (254:40).
Resuming data-datalvpooltdata_tmeta (254:40).
Creating data-datalvpooltdata_tdata
Loading table for data-datalvpooltdata_tdata (254:41).
Resuming data-datalvpooltdata_tdata (254:41).
Creating data-datalvpooltdata
Loading table for data-datalvpooltdata (254:42).
Resuming data-datalvpooltdata (254:42).
Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPonYy5uF9vqMtqiiYilhdeQZrmjXlo518-tpool for events
Creating volume group backup "/etc/lvm/backup/data" (seqno 23).
Converted data/datalvpooltdata and data/datalvpooltmeta to thin pool.
# lvs -a data
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
datalvpooltdata data twi-a-tz-- 1.00t 0.00 6.67
[datalvpooltdata_tdata] data Twi-ao---- 1.00t
[datalvpooltdata_tmeta] data ewi-ao---- 256.00m
[lvol0_pmspare] data ewi------- 256.00m

Nu is de naam nog niet wat ik wil. De oorspronkelijke naam van de meta-LV wordt overschreven met de naam van de data-LV, die twee krijgen toevoegingen _dmeta en _tdata, respectievelijk, en de resulterende thin LV pool krijgt de oorspronkelijke naam van de data-LV. Om de naam te krijgen die ik wil:

verwijder de thin LV pool
controleer of de onderliggende meta- en data-LV weer reguliere LV’s zijn
hernoem de data-LV
doe de conversie opnieuw

# lvremove data/datalvpooltdata
Do you really want to remove active logical volume data/datalvpooltdata? [y/n]: y
Logical volume "datalvpooltdata" successfully removed
# lvs -a data
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
archief data -wi-ao---- 800.00g
[cache_fotos] data Cwi---C--- 48.00g 2.82 9.16 0.00
[cache_fotos_cdata] data Cwi-ao---- 48.00g
[cache_fotos_cmeta] data ewi-ao---- 100.00m
fotos data Cwi-aoC--- 2.68t [cache_fotos] [fotos_corig] 2.82 9.16 0.00
[fotos_corig] data owi-aoC--- 2.68t
geluid data -wi-ao---- 16.56g
[lvol0_pmspare] data ewi------- 256.00m
muziekNR data -wi-ao---- 150.00g
pubNR data -wi-ao---- 8.00g
rom data -wi-ao---- 90.00g
ssdata data -wi-ao---- 40.00g
video data -wi-ao---- <1.09t

Opnieuw een verrassing: de onderliggende LV’s zijn meteen opgeruimd. Goed om te onthouden, ergens wel logisch: zonder de overkoepelende structuur heeft de meta-LV niet meer met de data-LV te maken, en zonder de metadata is de data niet meer te interpeteren (de fysieke sectoren worden niet lineair aan de thin LV’s toegewezen, dus alles staat door elkaar). Het staat ook zo in de handleiding: “Removing a thin pool LV removes both the data LV and metadata LV and returns the space to the VG.”

De naam van de meta-LV wordt overschreven, daar hergebruik ik het vorige commando. De naam van de data-LV wordt datatlvpool, voor (VG) data, thin logical volume pool.

# lvcreate -n datalvpooltmeta -L 255m data /dev/sdb4
Rounding up size to full physical extent 256.00 MiB
Logical volume "datalvpooltmeta" created.
# lvcreate -n datatlvpool -L 0.4t data /dev/sde1
Rounding up size to full physical extent 409.60 GiB
Logical volume "datatlvpool" created.
# lvconvert --type thin-pool --poolmetadata data/datalvpooltmeta data/datatlvpool
Thin pool volume with chunk size 384.00 KiB can address at most <94.88 TiB of data.
WARNING: Converting data/datatlvpool and data/datalvpooltmeta to thin pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/datatlvpool and data/datalvpooltmeta? [y/n]: yes
Converted data/datatlvpool and data/datalvpooltmeta to thin pool.
# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
datatlvpool data twi-a-t--- 409.60g 0.00 6.59
[datatlvpool_tdata] data Twi-ao---- 409.60g
[datatlvpool_tmeta] data ewi-ao---- 256.00m
[lvol0_pmspare] data ewi------- 256.00m

Ik wijs bij nader inzien minder ruimte toe aan de data-LV: groter maken gebeurt automatisch, maar kleiner maken wordt niet ondersteund.

Foto’s: minder dan 50GB/maand, dus zo’n 500GB/jaar
Films/video: enkele GB/maand, minder dan 100GB/jaar
400GB zou toereikend zijn voor ruim een half jaar

Ergens onderweg is lvol0_pmspare verdubbeld in grootte, voor de rest staat de basis hiermee. Nu de lvm.conf instellingen nalopen en de conversie van de LV’s op /dev/sda* naar extern origine uitvoeren.

# cat /etc/lvm/lvm.conf|grep autoextend    
    snapshot_autoextend_threshold = 100
    snapshot_autoextend_percent = 20
    thin_pool_autoextend_threshold = 100
    thin_pool_autoextend_percent = 20
    vdo_pool_autoextend_threshold = 100

Daarmee (treshold = 100) wordt nooit automatisch extra ruimte toegewezen, aanpassen dus! Ik zet de threshold op 95%, en het percentage waarmee dan de thin pool vergroot wordt op 10%.

Eerste test voor daadwerkelijk gebruik van thin LV met extern snapshot:

# umount /home/wbk/sounds 
# vgchange -an data/geluid
  Invalid volume group name data/geluid.
  Run `vgchange --help' for more information.
# lvchange -an data/geluid
# lvcreate -vt --type thin --thinpool datatlvpool -n geluidRW data/geluid
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Making thin LV geluidRW in pool datatlvpool in VG data using segtype thin.
    activation/volume_list configuration setting not defined: Checking only host tags for data/datatlvpool.
    Deactivating public thin pool data/datatlvpool.
  Cannot use writable LV as the external origin.
# lvchange --permission r data/geluid
  Logical volume data/geluid changed.
# lvcreate -vt --type thin --thinpool datatlvpool -n geluidRW data/geluid
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Making thin LV geluidRW in pool datatlvpool in VG data using segtype thin.
    activation/volume_list configuration setting not defined: Checking only host tags for data/datatlvpool.
    Deactivating public thin pool data/datatlvpool.
    Test mode: Skipping archiving of volume group.
    Creating logical volume geluidRW
    Test mode: Skipping backup of volume group.
    Test mode: Skipping activation, zeroing and signature wiping.
  Logical volume "geluidRW" created.
# lvcreate -v --type thin --thinpool datatlvpool -n geluidRW data/geluid
    Making thin LV geluidRW in pool datatlvpool in VG data using segtype thin.
    activation/volume_list configuration setting not defined: Checking only host tags for data/datatlvpool.
    Deactivating public thin pool data/datatlvpool.
    Not monitoring data/datatlvpool with libdevmapper-event-lvm2thin.so
    Unmonitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Removing data-datatlvpool (254:42)
    Executing: /usr/sbin/thin_check -q /dev/mapper/data-datatlvpool_tmeta
    Removing data-datatlvpool_tdata (254:41)
    Removing data-datatlvpool_tmeta (254:40)
    Archiving volume group "data" metadata (seqno 34).
    Creating logical volume geluidRW
    Creating volume group backup "/etc/lvm/backup/data" (seqno 35).
    activation/volume_list configuration setting not defined: Checking only host tags for data/datatlvpool.
    Creating data-datatlvpool_tmeta
    Loading table for data-datatlvpool_tmeta (254:33).
    Resuming data-datatlvpool_tmeta (254:33).
    Creating data-datatlvpool_tdata
    Loading table for data-datatlvpool_tdata (254:40).
    Resuming data-datatlvpool_tdata (254:40).
    Executing: /usr/sbin/thin_check -q /dev/mapper/data-datatlvpool_tmeta
    Creating data-datatlvpool-tpool
    Loading table for data-datatlvpool-tpool (254:41).
    Resuming data-datatlvpool-tpool (254:41).
    Creating data-datatlvpool
    Loading table for data-datatlvpool (254:42).
    Resuming data-datatlvpool (254:42).
    Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Loading table for data-datatlvpool_tdata (254:40).
    Suppressed data-datatlvpool_tdata (254:40) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:33).
    Suppressed data-datatlvpool_tmeta (254:33) identical table reload.
    Loading table for data-datatlvpool-tpool (254:41).
    Suppressed data-datatlvpool-tpool (254:41) identical table reload.
    Creating volume group backup "/etc/lvm/backup/data" (seqno 36).
    Activating logical volume data/geluidRW.
    activation/volume_list configuration setting not defined: Checking only host tags for data/geluidRW.
    Loading table for data-datatlvpool_tdata (254:40).
    Suppressed data-datatlvpool_tdata (254:40) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:33).
    Suppressed data-datatlvpool_tmeta (254:33) identical table reload.
    Loading table for data-datatlvpool-tpool (254:41).
    Suppressed data-datatlvpool-tpool (254:41) identical table reload.
    Creating data-geluid-real
    Loading table for data-geluid-real (254:43).
    Resuming data-geluid-real (254:43).
    Creating data-geluidRW
    Loading table for data-geluidRW (254:44).
    Resuming data-geluidRW (254:44).
    data/datatlvpool already monitored.
  Logical volume "geluidRW" created.
root@fractal:/var/log# lvs data/geluid data/geluidRW
  LV       VG   Attr       LSize  Pool        Origin Data%  Meta%  Move Log Cpy%Sync Convert
  geluid   data ori------- 16.56g                                                           
  geluidRW data Vwi-a-t--- 16.56g datatlvpool geluid 0.00

Dat ziet er goed uit. Wel weer een verrassing: bij het aankoppelen van geluidRW gebeurt er ‘niets’. Na wat puzzelen, lijkt er een mismatch te zijn tussen LVM-partities in /dev/mapper en de namen die lvs teruggeeft:

# mount /dev/mapper/data-geluidRW /home/wbk/sounds -o users
# ls /home/wbk/sounds/
# mount /dev/mapper/data-geluid /home/wbk/sounds -o users
mount: /home/wbk/sounds: special device /dev/mapper/data-geluid does not exist.
# ls /dev/mapper/data-gel*
/dev/mapper/data-geluid-real  /dev/mapper/data-geluidRW
# mount /dev/mapper/data-geluid-real /home/wbk/sounds -o users
mount: /home/wbk/sounds: /dev/mapper/data-geluid-real already mounted or mount point busy.
# partprobe
# lvscan -a |grep geluid
  inactive          '/dev/data/geluid' [16.56 GiB] inherit
  ACTIVE            '/dev/data/geluidRW' [16.56 GiB] inherit
# lsof|grep geluid
#

Bij het maken van de thin LV zijn er twee LV’s gemaakt: data-geluid-real en data-geluidRW, maar ik zie niets over data-geluid zelf. Misschien dat er een restart van een of ander proces nodig is. LVM2 kan ik niet zomaar restarten, ik probeer het met een reboot. Om tijdens het booten problemen te voorkomen, zet ik /dev/mapper/data-geluid in /etc/fstab in commentaar, en bij voorbaat veel van de overige data-LV’s.

… een reboot later …

@ ls /dev/mapper/data-gel*
/dev/mapper/data-geluid  /dev/mapper/data-geluid-real  /dev/mapper/data-geluidRW
# lvs -a |grep geluid
  geluid              data   ori-a-----  16.56g                                                                    
  geluidRW            data   Vwi-a-t---  16.56g datatlvpool   geluid        0.01                                   
# mount /dev/mapper/data-geluidRW /home/wbk/sounds -o users
# ls /home/wbk/sounds/
 20000101025420.amr   20080922191656.amr   20090324192216.amr   20111231180403.amr

Phew, ziet er nu wel goed uit. Het ‘-real’-record zie ik in lvs -a niet terug, Wel in /dev/mapper/ en met dmsetup:

# ls -l /dev/mapper/* |grep gelu   
lrwxrwxrwx 1 root root       8 Jan  2 11:35 /dev/mapper/data-geluid -> ../dm-34
lrwxrwxrwx 1 root root       8 Jan  2 11:35 /dev/mapper/data-geluid-real -> ../dm-33
lrwxrwxrwx 1 root root       8 Jan  2 11:35 /dev/mapper/data-geluidRW -> ../dm-45
# dmsetup ls --tree
....
data-geluidRW (254:45)
 ├─data-datatlvpool-tpool (254:43)
 │  ├─data-datatlvpool_tdata (254:42)
 │  │  └─ (8:65)
 │  └─data-datatlvpool_tmeta (254:41)
 │     └─ (8:20)
 └─data-geluid-real (254:33)
    └─ (8:1)
data-geluid (254:34)
 └─data-geluid-real (254:33)
    └─ (8:1)
....

Bij het schrijven naar de aangekoppelde partitie, als gebruiker, laat iostat zien dat er (inderdaad) naar de PV van de thin LV geschreven wordt, dus naar sde1 en niet naar sda*:

$ dd if=/dev/urandom of=bestand bs=1M count=4512
dd: error writing 'bestand': No space left on device
4469+0 records in
4468+0 records out
4685910016 bytes (4.7 GB, 4.4 GiB) copied, 29.7742 s, 157 MB/s
$ df -hT .
Filesystem                Type  Size  Used Avail Use% Mounted on
/dev/mapper/data-geluidRW ext4   17G   16G     0 100% /home/wbk/sounds
$ ls -hls bestand
4.4G -rw-r--r-- 1 wbk fam 4.4G Jan  2 14:23 bestand

# iostat -hd 3 /dev/sda[1239] /dev/sdb4 /dev/sdb4 /dev/sdd4 /dev/sde1
      tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn Device
     3.00         1.3k        26.7k       4.0k      80.0k sdb4
     0.00         0.0k         0.0k       0.0k       0.0k sda1
     0.00         0.0k         0.0k       0.0k       0.0k sda2
     0.00         0.0k         0.0k       0.0k       0.0k sda3
     0.00         0.0k         0.0k       0.0k       0.0k sda9
     0.00         0.0k         0.0k       0.0k       0.0k sdd4
   136.00         0.0k       169.4M       0.0k     508.2M sde1

$ df -T .
Filesystem                Type 1K-blocks     Used Available Use% Mounted on
/dev/mapper/data-geluidRW ext4  16962388 16077652         0 100% /home/wbk/sounds
# lvs -a data 
  LV                  VG   Attr       LSize   Pool        Origin     Data% Meta% 
  datatlvpool         data twi-aot--- 409.60g                        1.19  7.07                            
  [datatlvpool_tdata] data Twi-ao---- 409.60g                                                                    
  [datatlvpool_tmeta] data ewi-ao---- 256.00m                                                                   
  geluid              data ori-a-----  16.56g                                                                    
  geluidRW            data Vwi-aot---  16.56g datatlvpool geluid     29.48

Ook hier weer een verrassing: de thin LV ‘geluidRW’ is maar voor <30% gevuld, terwijl het bestandssysteem op de partitie voor 100% gevuld is. Ik probeer wat er gebeurt als ik thin LV geluidRW vergroot met 4GB:

# lvextend -tvr -L+4G data/geluidRW /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/geluidRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Skipping filesystem check for device "/dev/mapper/data-geluidRW" as the filesystem is mounted on /home/wbk/sounds
    /sbin/fsadm failed: 3
    Test mode: Skipping archiving of volume group.
    Extending logical volume data/geluidRW to 20.56 GiB
  Size of logical volume data/geluidRW changed from 16.56 GiB (4240 extents) to 20.56 GiB (5264 extents).
    Test mode: Skipping backup of volume group.
  Logical volume data/geluidRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/geluidRW 21561344K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Device "/dev/mapper/data-geluidRW" size is 17783848960 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluidRW"
fsadm: Resizing filesystem on device "/dev/mapper/data-geluidRW" to 22078816256 bytes (4341760 -> 5390336 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-geluidRW 5390336
# lvextend -vr -L+4G data/geluidRW /dev/sde1
    Executing: /sbin/fsadm --verbose check /dev/data/geluidRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Skipping filesystem check for device "/dev/mapper/data-geluidRW" as the filesystem is mounted on /home/wbk/sounds
    /sbin/fsadm failed: 3
    Archiving volume group "data" metadata (seqno 36).
    Extending logical volume data/geluidRW to 20.56 GiB
  Size of logical volume data/geluidRW changed from 16.56 GiB (4240 extents) to 20.56 GiB (5264 extents).
    Loading table for data-datatlvpool_tdata (254:42).
    Suppressed data-datatlvpool_tdata (254:42) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:41).
    Suppressed data-datatlvpool_tmeta (254:41) identical table reload.
    Loading table for data-datatlvpool-tpool (254:43).
    Suppressed data-datatlvpool-tpool (254:43) identical table reload.
    Loading table for data-geluid-real (254:33).
    Suppressed data-geluid-real (254:33) identical table reload.
    Loading table for data-geluidRW (254:45).
    Loading table for data-geluid-real (254:33).
    Suppressed data-geluid-real (254:33) identical table reload.
    Loading table for data-geluid (254:34).
    Suppressed data-geluid (254:34) identical table reload.
    Not monitoring data/datatlvpool with libdevmapper-event-lvm2thin.so
    Unmonitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Suspending data-geluidRW (254:45)
    Suspending data-datatlvpool-tpool (254:43)
    Suspending data-geluid-real (254:33)
    Suspending data-datatlvpool_tdata (254:42)
    Suspending data-datatlvpool_tmeta (254:41)
    Loading table for data-datatlvpool_tdata (254:42).
    Suppressed data-datatlvpool_tdata (254:42) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:41).
    Suppressed data-datatlvpool_tmeta (254:41) identical table reload.
    Loading table for data-datatlvpool-tpool (254:43).
    Suppressed data-datatlvpool-tpool (254:43) identical table reload.
    Loading table for data-geluid-real (254:33).
    Suppressed data-geluid-real (254:33) identical table reload.
    Resuming data-datatlvpool_tdata (254:42).
    Resuming data-datatlvpool_tmeta (254:41).
    Resuming data-datatlvpool-tpool (254:43).
    Resuming data-geluid-real (254:33).
    Resuming data-geluidRW (254:45).
    Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Creating volume group backup "/etc/lvm/backup/data" (seqno 37).
  Logical volume data/geluidRW successfully resized.
    Executing: /sbin/fsadm --verbose resize /dev/data/geluidRW 21561344K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Device "/dev/mapper/data-geluidRW" size is 22078816256 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluidRW"
fsadm: Resizing filesystem on device "/dev/mapper/data-geluidRW" to 22078816256 bytes (4341760 -> 5390336 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-geluidRW 5390336
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/data-geluidRW is mounted on /home/wbk/sounds; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 2
The filesystem on /dev/mapper/data-geluidRW is now 5390336 (4k) blocks long.
# lvs -a data 
  LV                  VG   Attr       LSize   Pool        Origin  Data%  Meta%       
  datatlvpool         data twi-aot--- 409.60g                     1.21   7.08                            
  [datatlvpool_tdata] data Twi-ao---- 409.60g                                                                    
  [datatlvpool_tmeta] data ewi-ao---- 256.00m                                                                    
  geluid              data ori-a-----  16.56g                                                                    
  geluidRW            data Vwi-aot---  20.56g datatlvpool geluid  24.06                                  
  [lvol0_pmspare]     data ewi------- 256.00m      
# df -hT /dev/mapper/data-geluidRW 
Filesystem                Type  Size  Used Avail Use% Mounted on
/dev/mapper/data-geluidRW ext4   21G   16G  3.8G  81% /home/wbk/sounds

Constateringen:

Het gebruikte deel van geluidRW is afgenomen met het toewijzen van extra ruimte
Er is een kleine impact op thin pool datatlvpool
Het bestandssysteem op de thin LV is ook groter, en heeft nu weer 3.8GB beschikbaar
De thin LV heeft een reservering van 20.56GB, waarvan de verdeling nu is:
- 16.56GB wordt 1-op-1 gelezen uit (read only) LV geluid. Daarvoor is geen fysieke ruimte in geluidRW. Die ruimte is dus nog beschikbaar in pool datatvlpool
- 4.4GB is geschreven in de fysieke ruimte van geluidRW. Daarvoor zijn naar rato fysieke eenheden van pool datatvlpool gebruikt
- 3.8GB is wel gereserveerd maar nog niet beschreven. Die ruimte is vrij in de pool datatvlpool, nog niet opgeeist door geluidRW en het is vrije ruimte in het bestandssysteem dat over thin LV geluidRW heen ligt.

In lvm.conf heb ik ‘discard’ op de standaardwaarde laten staan, dat is ‘passdown’. Als er in de thin LV een bestand weggegooid wordt waardoor fysieke eenheden vrijkomen, wordt de ruimte teruggegeven aan de pool en doorgegeven (passed down) naar beneden aan het apparaat dat daaronder ligt. Dat zou een RAID-constructie kunnen zijn, maar in mijn geval staan de PV’s rechtstreeks op de fysieke opslagmedia. De SSD of HDD krijgt (van LVM/device manager, via de kernel) bericht dat er blokken vrijgekomen zijn, zodat de trim-functie van de SSD of het interne huishouden van de SMR-schijf z’n werk kan doen. Als het meezit is de machine niet al te druk, en kan dat tussendoor een keer plaatsvinden. De media zijn dan weer beschikbaar als er vraag naar onbeschreven ruimte is, zonder dat er op dat moment low-level opruimwerk gedaan hoeft te worden. Bij een normale HDD geeft het iets overhead, omdat het bij zulke schijven niet nodig is om sectoren te wissen/vrij te maken voor ze weer beschreven kunnen worden.

Voorwaarde is wel dat LVM/device manager een discard moet ontvangen van het bestandssysteem. Voor ext4 kan het in /etc/fstab opgegeven worden, maar dat werd nog niet aanbevolen (actuele, 2020/2021 stand van zaken kan ik niet vinden).

Ik kan de discard-actie nu handmatig veroorzaken door fstrim te gebruiken. Als ik het bestand van 4,4GB weggooi en fstrim gebruik, moet de ruimte dus weer beschikbaar komen in de pool:

$ df  .
Filesystem                1K-blocks     Used Available Use% Mounted on
/dev/mapper/data-geluidRW  21090900 16077652   3963368  81% /home/wbk/sounds
$ rm ~sounds/bestand*
$ df  .
Filesystem                1K-blocks     Used Available Use% Mounted on
/dev/mapper/data-geluidRW  21090900 11501564   8539456  58% /home/wbk/sounds
# lvs -o+discards data/geluidRW
  LV       VG   Attr       LSize  Pool        Origin Data%  Meta%  Discards
  geluidRW data Vwi-aot--- 20.56g datatlvpool geluid 24.06         passdown
# lvs -o+discards data/datatlvpool
  LV          VG   Attr       LSize   Pool Origin Data%  Meta%  Discards
  datatlvpool data twi-aot--- 409.60g             1.21   7.08   passdown
# fstrim /home/wbk/sounds 
# lvs -o+discards data/geluidRW
  LV       VG   Attr       LSize  Pool        Origin Data%  Meta%  Discards
  geluidRW data Vwi-aot--- 20.56g datatlvpool geluid 0.33          passdown
# lvs -o+discards data/datatlvpool
  LV          VG   Attr       LSize   Pool Origin Data%  Meta%  Discards
  datatlvpool data twi-aot--- 409.60g             0.02   6.59   passdown

Leuk, geen verrassing deze keer! Er komt schot in de zaak, tijd voor iets nieuws blijkbaar. Ik meen gelezen te hebben dat verkleinen van thin LV’s niet mogelijk is, maar dat kan ik niet terugvinden. Omdat er nu nog geen (nuttige) data naar geluidRW geschreven is, geeft dat mooi een gelegenheid het te testen. Met lvextend vang ik bot, maar met lvreduce lijkt het goed te gaan zolang ik niet vertel dat het specifiek van /dev/sde1 weggehaald moet worden:

# lvextend -tvr -L-4G data/geluidRW /dev/sde1
  Size may not be negative.
  Invalid argument for --size: -4G
  Error during parsing of command line.
# lvextend -tvr -L16G data/geluidRW /dev/sde1
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  New size given (4096 extents) not larger than existing size (5264 extents)
# lvreduce -tvr -L-4G data/geluidRW 
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Executing: /sbin/fsadm --dry-run --verbose check /dev/data/geluidRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Skipping filesystem check for device "/dev/mapper/data-geluidRW" as the filesystem is mounted on /home/wbk/sounds
    /sbin/fsadm failed: 3
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/geluidRW 17367040K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Device "/dev/mapper/data-geluidRW" size is 22078816256 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluidRW"
fsadm: resize2fs needs unmounted filesystem
Do you want to unmount "/home/wbk/sounds" ? [Y|n] y
fsadm: Dry execution umount /home/wbk/sounds
fsadm: Dry execution fsck -f -p /dev/mapper/data-geluidRW
fsadm: Resizing filesystem on device "/dev/mapper/data-geluidRW" to 17783848960 bytes (5390336 -> 4341760 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-geluidRW 4341760
fsadm: Remounting unmounted filesystem back
fsadm: Dry execution mount /dev/mapper/data-geluidRW /home/wbk/sounds
    Test mode: Skipping archiving of volume group.
    Reducing logical volume data/geluidRW to 16.56 GiB
  Size of logical volume data/geluidRW changed from 20.56 GiB (5264 extents) to 16.56 GiB (4240 extents).
    Test mode: Skipping backup of volume group.
  Logical volume data/geluidRW successfully resized.
# lvreduce -tvr -L-4G data/geluidRW /dev/sde1
  Command does not accept argument: /dev/sde1.
root@fractal:~# lvreduce -vr -L-4G data/geluidRW 
    Executing: /sbin/fsadm --verbose check /dev/data/geluidRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Skipping filesystem check for device "/dev/mapper/data-geluidRW" as the filesystem is mounted on /home/wbk/sounds
    /sbin/fsadm failed: 3
    Executing: /sbin/fsadm --verbose resize /dev/data/geluidRW 17367040K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Device "/dev/mapper/data-geluidRW" size is 22078816256 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluidRW"
fsadm: resize2fs needs unmounted filesystem
Do you want to unmount "/home/wbk/sounds" ? [Y|n] y
fsadm: Executing umount /home/wbk/sounds
umount: /home/wbk/sounds: target is busy.
fsadm: Cannot proceed with mounted filesystem "/home/wbk/sounds".
  /sbin/fsadm failed: 1
  Filesystem resize failed.

Ja, de directory staat nog op verschillende plaatsen open. Sluiten en retry:

# lvreduce -vr -L-4G data/geluidRW 
    Executing: /sbin/fsadm --verbose check /dev/data/geluidRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Skipping filesystem check for device "/dev/mapper/data-geluidRW" as the filesystem is mounted on /home/wbk/sounds
    /sbin/fsadm failed: 3
    Executing: /sbin/fsadm --verbose resize /dev/data/geluidRW 17367040K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluidRW".
fsadm: Device "/dev/mapper/data-geluidRW" size is 22078816256 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluidRW"
fsadm: resize2fs needs unmounted filesystem
Do you want to unmount "/home/wbk/sounds" ? [Y|n] y
fsadm: Executing umount /home/wbk/sounds
fsadm: Executing fsck -f -p /dev/mapper/data-geluidRW
fsck from util-linux 2.33.1
geluid: 7753/1351680 files (1.3% non-contiguous), 2993002/5390336 blocks
fsadm: Resizing filesystem on device "/dev/mapper/data-geluidRW" to 17783848960 bytes (5390336 -> 4341760 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-geluidRW 4341760
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-geluidRW to 4341760 (4k) blocks.
The filesystem on /dev/mapper/data-geluidRW is now 4341760 (4k) blocks long.

fsadm: Remounting unmounted filesystem back
fsadm: Executing mount /dev/mapper/data-geluidRW /home/wbk/sounds
    Archiving volume group "data" metadata (seqno 37).
    Reducing logical volume data/geluidRW to 16.56 GiB
  Size of logical volume data/geluidRW changed from 20.56 GiB (5264 extents) to 16.56 GiB (4240 extents).
    Loading table for data-datatlvpool_tdata (254:42).
    Suppressed data-datatlvpool_tdata (254:42) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:41).
    Suppressed data-datatlvpool_tmeta (254:41) identical table reload.
    Loading table for data-datatlvpool-tpool (254:43).
    Suppressed data-datatlvpool-tpool (254:43) identical table reload.
    Loading table for data-geluid-real (254:33).
    Suppressed data-geluid-real (254:33) identical table reload.
    Loading table for data-geluidRW (254:45).
    Loading table for data-geluid-real (254:33).
    Suppressed data-geluid-real (254:33) identical table reload.
    Loading table for data-geluid (254:34).
    Suppressed data-geluid (254:34) identical table reload.
    Not monitoring data/datatlvpool with libdevmapper-event-lvm2thin.so
    Unmonitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Suspending data-geluidRW (254:45)
    Suspending data-datatlvpool-tpool (254:43)
    Suspending data-geluid-real (254:33)
    Suspending data-datatlvpool_tdata (254:42)
    Suspending data-datatlvpool_tmeta (254:41)
    Loading table for data-datatlvpool_tdata (254:42).
    Suppressed data-datatlvpool_tdata (254:42) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:41).
    Suppressed data-datatlvpool_tmeta (254:41) identical table reload.
    Loading table for data-datatlvpool-tpool (254:43).
    Suppressed data-datatlvpool-tpool (254:43) identical table reload.
    Loading table for data-geluid-real (254:33).
    Suppressed data-geluid-real (254:33) identical table reload.
    Resuming data-datatlvpool_tdata (254:42).
    Resuming data-datatlvpool_tmeta (254:41).
    Resuming data-datatlvpool-tpool (254:43).
    Resuming data-geluid-real (254:33).
    Resuming data-geluidRW (254:45).
    Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Creating volume group backup "/etc/lvm/backup/data" (seqno 38).
  Logical volume data/geluidRW successfully resized.
# df -h /home/wbk/sounds/
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/data-geluidRW   17G   11G  4.4G  72% /home/wbk/sounds

Kind kan de was doen, zou je bijna zeggen. In het kort voor elk van de LV’s op de SMR-schijf te doen:

umount /home/wbk/sounds
lvchange -an data/geluid
lvchange –permission r data/geluid
lvcreate –type thin –thinpool datatlvpool -n geluidRW data/geluid
Foutmelding over ontbrekende thin-pool, oid? Dan eerst de LV voor de pool aanmaken:
- lvcreate -v –type thin-pool -L 3T -n datatlvpool data

Telkens in plaats van geluid, een van de volgende LV’s nemen:

fotos
muziekNR
pubNR
rom
video

Toch weer een verrassing. Het resultaat is bijna hetzelfde als bij geluid: er wordt een verborgen LV ‘-real’ aangemaakt, maar deze keer is muziekRW na corrigeren van /ect/fstab meteen aan te koppelen:

# lvchange -an data/muziekNR
# lvchange --permission r data/muziekNR
  Logical volume data/muziekNR changed.
# lvcreate  --type thin --thinpool datatlvpool -n muziekRW data/muziekNR
  Logical volume "muziekRW" created.
# lvs -a data
  LV                  VG   Attr       LSize   Pool        Origin   Data%  Meta%  
  datatlvpool         data twi-aot--- 409.60g                      0.02   6.59                            
  [datatlvpool_tdata] data Twi-ao---- 409.60g                                                                    
  [datatlvpool_tmeta] data ewi-ao---- 256.00m                                                                    
  [lvol0_pmspare]     data ewi------- 256.00m                                                                    
  muziekNR            data ori------- 150.00g                                                                    
  muziekRW            data Vwi-a-t--- 150.00g datatlvpool muziekNR 0.00             
# ls /dev/mapper/data-muziek
data-muziekNR-real  data-muziekRW     
# vi /etc/fstab
# mount /home/wbk/music/
# ls /home/wbk/music/  
 allerlei
 audiobook
 Gandalf
 GEENMUZIEK
 lupin
 ...

Voor publiek toegankelijke LV pubNR:

# lvchange -an data/pubNR
# lvchange --permission r data/pubNR
  Logical volume data/pubNR changed.
# lvcreate  --type thin --thinpool datatlvpool -n pubRW data/pubNR
  Logical volume "pubRW" created.
# vi /etc/fstab
# vi /etc/fstab
# mount /dev/mapper/data-pubRW 
# ls /home/wbk/pubNR/
ftp  lost+found  recup_dir.1

Voor de rom-LV wil ik de naam aanpassen naar romRO. romROr met r voor recursief is mooier zijn, of romdOr. Dat breekt weer met NR (non-raid), RW (read/write) en RO (read-only), dus toch niet.

Voor videos alles op een rijtje. Bij lvextend kwam een hele rits inode-meldingen, ‘ignored’. Ik weet niet of een een bestandssysteem op een inactieve (RO) LV gerepareerd wordt. Ik zou denken dat eventuele reparaties op de actieve (RW) thin LV gedaan worden.

# lvrename data/video data/videoRO
  Renamed "video" to "videoRO" in volume group "data"
# umount /home/wbk/movies
# lvchange -an data/videoRO
# lvchange --permission r data/videoRO
  Logical volume data/videoRO changed.
# lvcreate  --type thin --thinpool datatlvpool -n videoRW data/videoRO
  Logical volume "videoRW" created.
# cat /etc/fstab|grep movies
##/dev/mapper/data-video /home/wbk/movies ext4    noatime,noexec  0       2
# vi /etc/fstab
# cat /etc/fstab|grep movies
/dev/mapper/data-videoRW /home/wbk/movies ext4    noatime,noexec  0       2
# lvextend -r -L+50G data/videoRW /dev/sde1  
fsck from util-linux 2.33.1
filmNR: Inode 17 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: Inode 19 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: Inode 20 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: Inode 2490370 extent tree (at level 2) could be narrower.  IGNORED.
filmNR: Inode 23461890 extent tree (at level 2) could be narrower.  IGNORED.
filmNR: Inode 23855108 extent tree (at level 1) could be shorter.  IGNORED.
filmNR: Inode 23855117 extent tree (at level 1) could be narrower.  IGNORED.
...
filmNR: Inode 60030985 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: 3724/73007104 files (10.6% non-contiguous), 291110129/292028416 blocks
  Size of logical volume data/videoRW changed from <1.09 TiB (285184 extents) to <1.14 TiB (297984 extents).
  Logical volume data/videoRW successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-videoRW to 305135616 (4k) blocks.
The filesystem on /dev/mapper/data-videoRW is now 305135616 (4k) blocks long.

root@fractal:~# mount /home/wbk/movies
# df -h /home/wbk/movies
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.2T  1.1T   52G  96% /home/wbk/movies

Bij het controleren of ik foto’s al verdund had, viel me de inconsistente naamgeving van de read-only ‘origin’ LV’s op. Bij wijze van test heb ik de muziekNR-LV hernoemd, alles werkt gewoon 🙂

# lvs data
  LV          VG   Attr       LSize   Pool          Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  archief     data -wi-a----- 800.00g                                                                    
  datatlvpool data twi-aot--- 409.60g                             1.65   7.18                            
  fotos       data Cwi-a-C---   2.68t [cache_fotos] [fotos_corig] 2.83   9.16            0.00            
  geluid      data ori-a-----  16.56g                                                                    
  geluidRW    data Vwi-aot---  16.56g datatlvpool   geluid        0.43                                   
  muziekNR    data ori------- 150.00g                                                                    
  muziekRW    data Vwi-aot--- 150.00g datatlvpool   muziekNR      3.87                                   
  pubNR       data ori-------   8.00g                                                                    
  pubRW       data Vwi-aot---   8.00g datatlvpool   pubNR         0.01                                   
  romRO       data -wi-ao----  90.00g                                                                    
  ssdata      data -wi-ao----  40.00g                                                                    
  videoRO     data ori-------  <1.09t                                                                    
  videoRW     data Vwi-aot---  <1.14t datatlvpool   videoRO       0.07                                   
# lvrename -tv data/muziekNR data/muziekRO
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Test mode: Skipping archiving of volume group.
    Test mode: Skipping backup of volume group.
  Renamed "muziekNR" to "muziekRO" in volume group "data"
root@fractal:~# lvrename -v data/muziekNR data/muziekRO
    Archiving volume group "data" metadata (seqno 52).
    Loading table for data-datatlvpool_tdata (254:42).
    Suppressed data-datatlvpool_tdata (254:42) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:41).
    Suppressed data-datatlvpool_tmeta (254:41) identical table reload.
    Loading table for data-datatlvpool-tpool (254:43).
    Suppressed data-datatlvpool-tpool (254:43) identical table reload.
    Loading table for data-muziekNR-real (254:37).
    Suppressed data-muziekNR-real (254:37) identical table reload.
    Loading table for data-muziekRW (254:46).
    Suppressed data-muziekRW (254:46) identical table reload.
    Not monitoring data/datatlvpool with libdevmapper-event-lvm2thin.so
    Unmonitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Suspending data-muziekRW (254:46)
    Suspending data-datatlvpool-tpool (254:43)
    Suspending data-muziekNR-real (254:37)
    Suspending data-datatlvpool_tdata (254:42)
    Suspending data-datatlvpool_tmeta (254:41)
    Loading table for data-datatlvpool_tdata (254:42).
    Suppressed data-datatlvpool_tdata (254:42) identical table reload.
    Loading table for data-datatlvpool_tmeta (254:41).
    Suppressed data-datatlvpool_tmeta (254:41) identical table reload.
    Loading table for data-datatlvpool-tpool (254:43).
    Suppressed data-datatlvpool-tpool (254:43) identical table reload.
    Loading table for data-muziekNR-real (254:37).
    Suppressed data-muziekNR-real (254:37) identical table reload.
    Loading table for data-muziekRW (254:46).
    Suppressed data-muziekRW (254:46) identical table reload.
    Resuming data-datatlvpool_tdata (254:42).
    Resuming data-datatlvpool_tmeta (254:41).
    Resuming data-datatlvpool-tpool (254:43).
    Renaming data-muziekNR-real (254:37) to data-muziekRO-real
    Resuming data-muziekRO-real (254:37).
    Resuming data-muziekRW (254:46).
    Monitored LVM-OHMt6RDBp5VnJD9hQdjwYm5yfUSKWCDPezYY3rnhKDVAyfaQI76PcSbAdHdkZYu0-tpool for events
    Creating volume group backup "/etc/lvm/backup/data" (seqno 53).
  Renamed "muziekNR" to "muziekRO" in volume group "data"

Dat kan met veel minder output, zoals hier voor geluid:

# lvrename  data/geluid data/geluidRO
  Renamed "geluid" to "geluidRO" in volume group "data"

Voor de foto-LV doe ik de check van het bestandssysteem voorafgaand aan het inactief zetten van de LV, aansluitend verdunnen en vergroten (eindelijk…)

# fsck.ext4 /dev/mapper/data-fotos
e2fsck 1.44.5 (15-Dec-2018)
foto has gone 208 days without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
foto: 251505/2813440 files (39.3% non-contiguous), 684036576/720210944 blocks
# lvrename data/fotos data/fotosRO
  Renamed "fotos" to "fotosRO" in volume group "data"
root@fractal:~# lvchange -an data/fotosRO
root@fractal:~# lvchange --permission r data/fotosRO
  Logical volume data/fotosRO changed.
# lvcreate --type thin --thinpool datatlvpool -n fotosRW data/fotosRO
  WARNING: Sum of all thin volume sizes (3.99 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<2.02 TiB).
  Logical volume "fotosRW" created.
# cat /etc/fstab|grep fotos
##/dev/mapper/data-fotos /home/wbk/photos ext4    noatime,noexec 0       2
# cat /etc/fstab|grep fotos
/dev/mapper/data-fotosRW /home/wbk/photos ext4    noatime,noexec 0       2
root@fractal:~# lvextend -r -L+100G data/fotosRW /dev/sde1
fsck from util-linux 2.33.1
foto: clean, 251505/2813440 files, 684036576/720210944 blocks
  WARNING: Sum of all thin volume sizes (<4.09 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<2.02 TiB).
  Size of logical volume data/fotosRW changed from 2.68 TiB (703331 extents) to 2.78 TiB (728931 extents).
  Logical volume data/fotosRW successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-fotosRW to 746425344 (4k) blocks.
The filesystem on /dev/mapper/data-fotosRW is now 746425344 (4k) blocks long.
root@fractal:~# df -hTt ext4
Filesystem                Type  Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW  ext4  2.8T  2.6T   99G  97% /home/wbk/photos

Van alle bewerkingen (los van het verplaatsen van VG’s van de ene schijf naar de andere bij het leegmaken van de oude schijven), duurde de wijziging van deze LV het langst, maar nog steeds binnen enkele minuten.

Hiermee is de saga zo ongeveer ten einde. Todo’s:

/homes als external origin voor thin LV aanwijzen
lvrename van homes-home naar homes-homeRO
/home/wbk als external origin voor thin LV aanwijzen
lvrename van homes-wbk naar homes-wbkRO

Vrijwel alle bestandssystemen hangen in /home of in /home/wbk, en zodra ik inlog zijn de bestanden in /home/wbk in gebruik. Trucjes helpen niet, umount -l, mount -o remount,ro : allebei geen succes, ook niet na switchen naar single-user mode via telinit 1. Reboot dus, en in GRUB kiezen voor recovery en inloggen als root ipv ctrl-d om de normale boot voort te zetten.

 # lvcreate -v --type thin-pool -L 800G -n homestlvpool homes
  /dev/sdc: open failed: No medium found
    Setting chunk size to 512.00 KiB.
  Thin pool volume with chunk size 512.00 KiB can address at most 126.50 TiB of data.
    Preferred pool metadata size 100.00 MiB.
    Making pool homestlvpool in VG homes using segtype thin-pool
    Archiving volume group "homes" metadata (seqno 21).
    Creating logical volume homestlvpool
    activation/volume_list configuration setting not defined: Checking only host tags for homes/homestlvpool.
    Creating homes-homestlvpool
    Loading table for homes-homestlvpool (254:25).
    Resuming homes-homestlvpool (254:25).
    Initializing 4.00 KiB of logical volume "homes/homestlvpool" with value 0.
    Removing homes-homestlvpool (254:25)
    Creating logical volume homestlvpool_tmeta
    Creating logical volume homestlvpool_tdata
    Creating volume group backup "/etc/lvm/backup/homes" (seqno 23).
    Activating logical volume homes/homestlvpool.
    activation/volume_list configuration setting not defined: Checking only host tags for homes/homestlvpool.
    Creating homes-homestlvpool_tmeta
    Loading table for homes-homestlvpool_tmeta (254:25).
    Resuming homes-homestlvpool_tmeta (254:25).
    Creating homes-homestlvpool_tdata
    Loading table for homes-homestlvpool_tdata (254:26).
    Resuming homes-homestlvpool_tdata (254:26).
    Creating homes-homestlvpool
    Loading table for homes-homestlvpool (254:27).
    Resuming homes-homestlvpool (254:27).
    Monitored LVM-mbnSwLqfZ9AQdDOJomVPhP76nuV6tX8WTafMmPQKm45r5XfNrefU9gCltUwvLkn3-tpool for events
  Logical volume "homestlvpool" created.
 # umount /home/wbk
 # lvrename homes/wbk homes/wbkRO
 # lvchange -an homes/wbkRO
 # lvchange --permission r homes/wbkRO
 # lvcreate --type thin --thinpool homestlvpool -n wbkRW homes/wbkRO
 # lvchange -an homes/homeRO
 # lvchange --permission r homes/homeRO
 # lvcreate --type thin --thinpool hometlvpool -n homesRW homes/homeRO

De ontbrekende /dev/sdc gaf me wat bedenkingen, het lijkt of een aantal disks opgeschoven is qua nummering.

Bij het opslaan van het tmux-scherm heb ik blijkbaar wat foutgedaan, of ik heb een van de logs overscreven met de ander. Ik heb nu twee identieke logs, en geen feedback van de laatste 8 opdrachten. Het resultaat lijkt wel in orde.

Het meeste is nu gebeurt. Nog te doen:

Controleren of het reeds ingerichte cache voor de LV’s nu voor de thin-LV’s actief is
Tekst fatsoeneren zodat het later nog leesbaar is
Controleren of er nog todo’s in staan die ik ondertussen over het hoofd gezien heb
Misschien nog een in het Engels publiceren, hoewel er in het Engels al voldoende te vinden is over LVM.

Print this entry

31 oktober 202018 april 2021

Schijfmigratie met LVM – wat hoort waar

De schijfruimte op de mediaserver/NAS die dienstdoet als m’n werkstation, loopt uit vrije opslagruimte.

En al een tijdje uit vrije SATA-aansluitingen. Vanwege het stroomverbruik van een PCIe-SATA-insteekkaart zit die er nog niet in, als dat al ooit komen gaat. Er ligt er een klaar, maar daar _moet_ echt een fannetje op (dus herrie), en het verbruik van ruim 20W (lokale download van huidige versie van het document) is een derde van het huidige systeem.

Kleine schijven vervangen door grotere is een andere optie. Het stroomverbruik zou, met voortgang van de techniek, voor een grotere schijf lager kunnen liggen dan met de kleinere oudere schijf. De oude schijven hebben er bijna tien jaar gebruik op zitten, vrijwel ononderbroken. Ze maken nog geen vervelende geluiden, maar preventief vervangen kan na die tijd geen kwaad.

De schijven die ik beschikbaar heb, zijn:

4TB Seagate; gevuld met incrementele back-ups via Borg-backup.
6TB Seagate; ligt al een tijdje. Het is een SMR-schijf, waarvoor ik eerst host-based SMR wilde uitzoeken. Tot zover geen succes. Blijft dus voorlopig device-based, de firmware beslist dus wat er wanneer hoe op de schijf gezet wordt, en waarzo. Of mij dat gelegen komt, heeft er niets mee te maken.
8TB Western Digital; net nieuw. De directe aanleiding om aan de slag te gaan.
480GB Crucial SSD; uit de laptop van mijn vrouw, nu die wegens plaatsgebrek vervangen is door een 960GB-exemplaar.

Zomaar een schijf erin pluggen gaat niet. In de loop van de tijd is de configuratie qua schijven gewisseld, met als kern een set van drie Western Digital 2GB schijven in RAID5 via mdadmin. Dat geeft een nuttige brutto opslagruimte van 4TB, waar LVM overheen ligt en in de eerste instantie het volledige systeem, op de groei.

Die 4TB zijn ondertussen vrijwel volledig gevuld met foto’s van de afgelopen 25 jaar. Films, video’s, muziek, boeken en ROMs staan niet meer op RAID-ondersteunde LVM. Systeemdirectories nog wel, deels op RAID1 over die drie schijven en deels in LVM op RAID5.

Er zijn zes SATA-poorten ingebouwd op het moederbord, naast de drie 2GB schijven zijn er een 3TB schijf, een kleine SSD voor caching en databases en een HDD met onbekende grootte ingebouwd.

Om een grotere schijf in te kunnen bouwen, moet er eerst eentje uit. Daarnaast wil ik de SSD vervangen door de grotere van 480GB, en de caching op LVM-niveau laten werken. Met de wirwar aan kabels is het niet heel duidelijk welke hardware op welke poort aangesloten is en zijn de schijven niet makkelijk uit de behuizing te trekken. Labels lezen op de schijven gaat dus lastig, schijven matchen met systeemeigenschappen ook.

Bij het vissen naar de huidige configuratie kwam ik wat raars tegen. Een van de 2TB WD Red-schijven deed deed zich voor als 6TB Red. Op internet wel problemen gevonden van mensen wier 6TB als 2TB gezien werd, maar niet andersom.

Ik ben een paar keer bezig geweest met Photorec, bij mogelijk gewiste SD-kaartjes en voor oude defecte schijven. Backups van MBR’s gemaakt, maar niet bewust teruggeschreven. Ik houd op die momenten in de gaten dat ik niet de verkeerde schijf aanspreek, maar je weet maar nooit.

De 6TB SMR-schijf heeft in de machine gezeten. Ik ben onlangs bezig geweest de images van de kleine schijven uit te pluizen, heb ik misschien iets overschreven? Volgens DF zitten er van WD 4 schijven in de kast: 3x Red, in RAID, en 1x de oude Green. Op onderzoek.

De bovenste schijf ligt er los in: de 2,5″ SSD van ~100GB. Zolang ik geen programma’s start waar een database achter zit, en op systeemniveau PostgresSQL en MySQL uitzet, kan ik die loskoppelen: sync disks, umount, hot-unplug power en data.

Met dat uit de weg kan ik het label van de schijf daaronder lezen: 3TB Toshiba, door het systeem herkend als een Hitachi-schijf,Hitachi Deskstar 5K3000. De schijf is van december 2012, dus vlak nadat destijds de 3,5″-productie van Hitachi via WD naar Toshiba ging.

Ik kan de schijf pas hardwarematig loskoppelen nadat de software ontkoppeld is. Onder welke koppelpunten is de data op deze schijf beschikbaar?

Spoorzoeken met mount, df, pvs, vgs, lvs en /etc/fstab. De 3TB schijf is te vinden als /dev/sdf:

root@fractal:~# fdisk -l /dev/sdf
Disk /dev/sdf: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: Hitachi HDS5C303
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D03ED4D8-E7F1-4550-8CEE-762B1263FEBC

Device Start End Sectors Size Type
/dev/sdf1 3563204608 5860532223 2297327616 1.1T Microsoft basic data
/dev/sdf2 2237691904 3563204607 1325512704 632.1G Microsoft basic data
/dev/sdf3 2048 209717247 209715200 100G Linux LVM

Partition table entries are not in disk order.

Vanuit de fysieke partities zijn de physical volumes in LVM te vinden:

root@fractal:~# pvs|grep 'sdf|PV'
PV        VG           Fmt  Attr PSize    PFree
/dev/sdf1 data-nonraid lvm2 a--    <1.07t      0
/dev/sdf2 data-nonraid lvm2 a--   632.05g 273.50g
/dev/sdf3 mailtemp     lvm2 a--  <100.00g <70.00g

Twee volumegroepen op de schijf, data-nonraid en mailtemp. Welke logische volumes er aangemaakt zijn in de volumegroepen is te zien met lvs:

root@fractal:~# lvs|grep 'mailtemp|data-nonraid'
LV       VG           Attr       LSize  ...
homesNR  data-nonraid -wi-a----- 90.00g
muziekNR data-nonraid -wi-ao---- 150.00g
pubNR    data-nonraid -wi-ao---- 100.00g
video    data-nonraid -wi-ao---- <1.09t
mail     mailtemp -wi-ao---- 30.00g

Met vgs is te vinden hoeveel fysieke en logische volumes er bij een volumegroep betrokken zijn. Ter controle of de opsomming hierboven volledig is:

root@fractal:~# vgs |grep 'data-nonraid|mailtemp|VG'
VG           #PV #LV #SN Attr   VSize    VFree
data-nonraid   2   4   0 wz--n-   <1.69t 273.50g
mailtemp       1   1   0 wz--n- <100.00g <70.00g

Drie PV’s in totaal, en 5 LV’s. Dat is wat ik hierboven ook vond. Om het systeem zonder problemen te kunnen starten moeten de partities niet automatisch gekoppeld worden bij het starten van het systeem. Partities die niet automatisch gekoppeld worden, maar nu wel gekoppeld zijn, zijn terug te vinden met mount of df.

root@fractal:~# cat /etc/fstab|grep 'mailtemp\|NR\|video'
/dev/mapper/data--nonraid-video /home/wbk/movies ext4 noatime,noexec 0 2
/dev/mapper/data--nonraid-pubNR /home/wbk/pubNR ext4 noatime,noexec 0 2
/dev/mapper/data--nonraid-muziekNR /home/wbk/music ext4 noatime,noexec 0 2
# video-lv is vervallen omdat alle video's over zijn naar de foto-lv
#/dev/mapper/data-video /home/wbk/video ext4 noexec 0 2
/dev/mapper/mailtemp-mail /var/vmail ext4 defaults 0 2
/home/wbk/pubNR/ftp/ /home/wbk/photos/ftp none bind 0 2
/home/wbk/pubNR/ftp/vsm/foto /var/www/ftp/vsm/foto none bind 0 2
/home/wbk/pubNR/ftp/suirankan/foto /var/www/ftp/suirankan/foto none bind 0 2
/home/wbk/pubNR/ftp/limesco/foto /var/www/ftp/limesco/foto none bind 0 2
/dev/mapper/data--nonraid-homesNR /home/nonraid ext4 noatime,noexec,noauto,noatime,nodiratime 0 2

Reservekopie van /etc/fstab en de mounts van de partities in commentaar zetten.

Het zou voldoende zijn de aangekoppelde bestandssystemen te syncen en los te koppelen voor ik de schijf fysiek loskoppel, maar met draaiende schijven zit me dat minder lekker dan met SSD’s. Dus: machine afsluiten, schijf loskoppelen, reboot, resultaat bekijken.

Print this entry