Open Source, Boudewijns angle

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:

• LVM caching examples
• SSD cache device to a hard disk drive using LVM
• ‘using LVM cache for storage tiering’
• How to set up SSD cache on LVM under Proxmox

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

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