Voor de volgende keer…

Door omstandigheden is het de afgelopen jaren drie keer keer nodig geweest mijn workstation in te richten. De eerste keer ging het enkel om uitwisselen van opslagruimte, zoals eerder beschreven.

De al wat oudere C7SIM-Q met eerste generatie i3 voldeed in vrijwel alle opzichten, alleen het maximum geheugen van 16 GB zat zo nu en dan in de weg. Ik heb het bord kunnen vervangen door een X11SSH-LN4F. Ook met i3, maar wel 6e generatie, en 32 GB RAM met uitbreidingsmogelijkheid tot 64 GB. Bovendien is het nu DDR4 ECC geheugen, waar het eerst DDR3 zonder ECC was.

Toen ik het moederbord verving zat er in een van de bestaande volumes iets scheef (ze het eerdere verhaal); de kortste weg naar een werkend systeem was een nieuwe installatie – met UEFI.

Installeren op UEFI geeft me vaak problemen bij het inrichten van de UEFI-partitie, meestal kom ik niet weg zonder installatie naar ‘removable storage’, maar het werkt uiteindelijk wel. Bij dit moederbord niet. Daarbij komt dat het moederbord, met remote management, wat geavanceerder is. Nadeel is dat boot voorbij ‘BIOS’ een stuk langer duurt; troubleshoot kost heel veel tijd.

Uiteindelijk heb ik Debian volledig automatisch laten installeren, met alle opties op default en minimale ingreep in het partitioneren. Daarmee werkte het eindelijk, maar ik had voor een kleine /var-partitie gekozen, waar vrij veel optionele pakketten in terechtkwamen. Zoveel, dat er voor Apt geen ruimte was om nieuwe programma’s te downloaden. Bovendien stond alles op defaultwaarden, met voeten in Fahrenheit en een Amerikaanse tijdzone. Daarnaast stond alles op een SSD die ik niet voor het systeem in gedachten had.

Snel was het wel! Door tien jaar upgrades over te slaan, merk je bij een upgrade veel meer van de vooruitgang. Niet alleen ruim voldoende geheugen (de 16 GB was niet dagelijks een bottleneck), maar vooral sneller geheugen. De CPU heeft geen veel hogere kloksnelheid, maar kan wel sneller schakelen en heeft geavanceerdere functies waardoor bestanden uitpakken bijvoorbeeld veel sneller gaat. Het systeem draaide nu niet op SSD-cached LVM-volumes, maar op LVM-volumes rechtstreeks op een (ouder model, SATA2) SSD.

Het nieuwe moederbord heeft plaats voor een NVMe-reepje. In tegenstelling tot mijn eerste ingeving, 2e-hands een zo klein en goedkoop mogelijk reepje aanschaffen, heb ik er een nieuwe ingeprikt: in veel gevallen zijn de 2e-hands exemplaren duurder dan een nieuwe. Met een paar euro extra bovenop de laagst geprijsde SSD heb ik me verwend met een ouder model Samsung. Met krap 2 TB aan 3-bits TLC NAND is er voldoende ruimte voor systeempartities, home partities, databasepartities en partities voor caching van datavolumes.

Met minimale moeite is de installatie, met UEFI, in een keer geslaagd. Daar zit je dan, in een mum van tijd met een kale installatie. Want snel dat ging het wel! Een flink deel van het TLC NAND wordt als SLC NAND ingezet, om snel de gigabyte aan DDR-geheugen te vereeuwigen. Waarschijnlijk haal ik het maximum er niet uit: de SSD heeft een 4xPCIe3 interface, terwijl de aansluiting op het moederbord er slechts 2 kanalen biedt.

Aanvullende instellingen / applicaties / packages

Todo’s: er zijn wat instellingen te doen en aanvullende packages te downloaden. Installeer eerst de programma’s, anders kun je ze niet inrichten natuurlijk.

Packages installeren:

apt update
apt upgrade 
apt install openssh-server screen tmux links htop powertop dstat sysstat nicstat curl sshfs # altijd handig
apt install lvm2 thin-provisioning-tools # systeem-onderdelen
apt install firefox dolphin dolphin-nextcloud nextcloud-desktop nextcloud-desktop-cmd   kdeconnect konsole vlc subtitlecomposer # in grafische omgeving (ook NC-cmd!)
apt install growlight # diskmanagement, onderweg tegengekomen

Overige software

Niet alle software is beschikbaar via Apt, of is de AppImage-versie net wat nieuwer dan de versie in Apt.

  • DigiKam; even kijken hoever Apt achter loopt –> Apt heeft v7, laatste appimage is v8
  • Chrysalis; nog niet in Apt

Firefox

  • Firefox sync instellen
  • Sync-server aanpassen in about:config ; zoeken naar token en vind identity.sync.tokenserver.uri, zet die op https://ffs.osba.nl/ffsync/token/1.0/sync/1.5
  • Eventueel synchronisatie van autoscroll uitzetten, omdat de defaultwaarde op verschillende platforms niet gelijk is, services.sync.prefs.sync.general.autoScroll op false
  • Inloggen via de sync-instellingen in Firefox. De eerste keer gebeurt er waarschijnlijk niets (alleen tabs kunnen dan naar een ander apparaat gestuurd worden, maar synchronisatie vindt niet plaats). Tot nu toe kunnen oplossen door alle synchronisatievinkjes uit te zetten, Firefox te restarten, uitloggen uit het Firefox-account, Firefox restarten, en dan weer inloggen. De tweede keer is het niet nodig een bevestigingscode door te geven, maar start de synchronisatie wel. Foutlogs zijn te vinden via about:sync-log, er is ook een sync-extension die daarna info weergeeft op about:sync

Nextcloud sync instellen

  • app-password instellen via personal settings –> security –> nieuwe entry maken onderaan de pagina ; de ingevoerde omschrijving zie je later pas, je hebt nu je eigen (getoonde) gebruikersnaam nodig en het random wachtwoord. Houdt ’t wachtwoord even in beeld, niet op ‘Done’ klikken
  • Nextcloud desktop openen en verbinden met https://online.osba.nl/nextcloud
  • Kopieer de link (hij opent vanzelf, maar het kan zijn dat de timeout te snel verstrijkt)
  • Open de link in een incognito-venster (om te voorkomen dat er automatisch ingelogd wordt met de reguliere gebruikersnaam)
  • Klik op ‘use an app token’, oid (de onderste optie)
  • Gebruik de eerder aangemaakte credentials
  • Als het niet werkte, nog een keer proberen. Als het wel werkte volgt er een melding, “Account connected”

Met de sync-client op Android gaat het nog makkelijker: in plaats van handmatig de gegevens invullen en overnemen: maak het app password aan, klik op ‘Show QR code for mobile apps’ en scan de code met je telefoon.

Dolphin

dolphin-nextcloud geeft een contextmenu waarin Nextcloud-bewerkingen vrijgegeven worden.

Met de Nextcloud Desktop client wordt synchronisatie geregeld, maar geen integratie. Installeer dolphin-nextcloud om vanuit Dolphin bestanden via Nextcloud te delen.

Voeg onder het Remote-kopje in de “Places” zijbalk een link naar Nextcloud toe via WebDAV en SSHFS. SSHFS geeft snellere toegang en betere integratie aan deze kant van de verbinding, maar wijzigingen worden niet door Nextcloud opgemerkt. WebDAV wordt aan deze kant echt als remote gezien, wat soms voor caching of vertraging zorgt, maar loopt via de Nextcloud-logica. Wijzigingen, verwijderingen en toevoegingen zijn meteen in Nextcloud beschikbaar.

De WebDAV link geeft Nextcloud via de web-interface, bij het kopje met settings linksonderin bij bestanden: https://online.osba.nl/nextcloud/remote.php/dav/files/wbk

Pas de link aan naar webdavs://online.osba.nl/nextcloud/remote.php/dav/files/wbk om hem in Dolphin te gebruiken. Meteen plakken in de adresbalk, en dan de locatie opslaan werkt het eenvoudigst; het werkt ook via Knetattach (de knop rechtsbovenin het scherm als je in Dolphin op Network klikt, onder remote).

Knetattach foutmelding, met op de achtergrond de (hoogst waarchijnlijk correcte) instellingen

Op welke manier dan ook: soms werkt het in ene keer, soms werkt het totaal niet. Deze keer is het een “totaal niet”-geval. Troubleshoot gaat erg moeizaam; Dolphin noch Knetattach geven enige feedback naast “The file or folder … does not exist” (Dolphin) of “Unable to connect to server. Please check your settings and try again.”
Een enkele keer lijkt het proces een stap verder te komen: dan volgt er een vraag of ik zeker weet dat ik wil inloggen op Nextcloud, om vervolgens alsnog te vertellen dat de file or folder does not exist.

De “bookmark” in Dolphin’s places-balk heb ik uit de settings van de oude installatie gehaald (~/.local/share/user-places.xbel)

De locatie in Dolphin, met op de achtergrond de ‘does not exist’-melding

Mogelijk zit de KWallet-entry voor Nextcloud-Desktop in de weg. Die client logt in met een app-password, maar in KWallet lijkt het een reguliere user/pass combinatie. Misschien geeft KWallet onder water het verkeerde wachtwoord (of het goede wachtwoord, maar via het verkeerde mechanisme) aan Dolphin en Knetattach door, zonder daar feedback over te geven. Na sluiten van zowel de wallet als de NC-client lukt het echter nog steeds niet. Wordt vervolgd.

GUI / gebruikersinstellingen

Fonts ophalen

  • De fonts Linux Biolinum en Linux Libertine zijn na 2012 gefork’d; releases van de vork zijn te vinden onder Libertinus op Github.
  • Pak het release file uit en (in het geval van KDE) gooi de bestanden in de fontmanager om ze te installeren.

Mountpoints inrichten

Voorheen waren datapartities zoals voor foto’s en video’s rechtstreeks in m’n home-directory gemount. Ik mount ze nu in een gebruiker-agnostische directory, en bind-mount ze lokaal.

De eerder o-zo-mooi ingerichte LVM is goed over te dragen, ware het niet dat:

  • ik een van de fysieke volumes een beetje verziekt heb
  • de tools om LVM te beheren na x jaar anders verpakt zijn en sommige binaries lijken te ontbreken; vgchange -ay data had LVM klachten:
root@fractal:~# vgchange -ay data
  /usr/sbin/cache_check: execvp failed: No such file or directory
  WARNING: Check is skipped, please install recommended missing binary /usr/sbin/cache_check!
  /usr/sbin/thin_check: execvp failed: No such file or directory
  WARNING: Check is skipped, please install recommended missing binary /usr/sbin/thin_check!
  14 logical volume(s) in volume group "data" now active

Het ontbrekende pakket blijkt thin-provisioning-tools

(Eenmalige todo’s: boeken en bieb naar data, geenmuziek naar home)

Keyboard

Ctrl+Alt+Backspace om X de nek om te draaien: advanced keyboard tab in KDE settings:

Alternatief: Alt+SysRq+k

Systeeminstellingen

Netwerk

Twee NIC’s samen laten werken als bond0. Met het vernietigen van de root-directory is de configuratie in /etc/network/interfaces helaas verloren gegaan. Er staat nog een todo op het lijstje, “/etc in git onderbrengen”, maar dat helpt nu niet.

De nieuwerwetse huidige installatie heeft autoconfig voor netwerk, waarschijnlijk via networkmanager. nmcli kan bonding interfaces aanmaken. De man-pages van nmcli zijn erg uitgebreid maar daar kan ik niet eenvoudig de bond-syntax terugvinden. Er is onder andere documentatie te vinden bij Red Hat en bij Gnome; die bij Red Hat heeft meer diepgang, die bij Gnome geeft passende voorbeelden.

# nmcli connection add type bond con-name bond0 mode 6
Connection 'bond0' (cf29cf16-692b-4925-95fd-0102aa758cc0) successfully added.
# nmcli device status
DEVICE  TYPE      STATE         CONNECTION         
eno2    ethernet  connected     Wired connection 1 
eno1    ethernet  disconnected  --                 
eno3    ethernet  unavailable   --                 
eno4    ethernet  unavailable   --                 
lo      loopback  unmanaged     --     
# nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname eno1 master bond0
Connection 'bond0-port1' (1a8cdccb-1363-40f5-b9aa-072936ca1544) successfully added.
# nmcli device status 
DEVICE   TYPE      STATE        CONNECTION         
eno2     ethernet  connected    Wired connection 1 
nm-bond  bond      connected    bond0              
eno1     ethernet  connected    bond0-port1        
eno3     ethernet  unavailable  --                 
eno4     ethernet  unavailable  --                 
lo       loopback  unmanaged    --                 

Aanmaken van een bonded interface ondersteund de networkmanager-GUI (nog?) niet, maar onderhoud/beheer ervan wel. Nadat eno1 aan bond0 gehangen was hierboven, maakte nm de verbinding actief. In de GUI heb ik ‘Wired connection 1’ verwijderd om geen verrassingen te krijgen bij het koppelen van eno2 aan bond0:

# nmcli device status 
DEVICE   TYPE      STATE         CONNECTION  
nm-bond  bond      connected     bond0       
eno1     ethernet  connected     bond0-port1 
eno2     ethernet  disconnected  --          
eno3     ethernet  unavailable   --          
eno4     ethernet  unavailable   --          
lo       loopback  unmanaged     --          
# nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname eno2 master bond0
Warning: There is another connection with the name 'bond0-port1'. Reference the connection by its uuid '67af71f7-f7b5-4f50-a02e-0fcfa4910960'
Connection 'bond0-port1' (67af71f7-f7b5-4f50-a02e-0fcfa4910960) successfully added.
# nmcli device status 
DEVICE   TYPE      STATE        CONNECTION  
nm-bond  bond      connected    bond0       
eno1     ethernet  connected    bond0-port1 
eno2     ethernet  connected    bond0-port1 
eno3     ethernet  unavailable  --          
eno4     ethernet  unavailable  --          
lo       loopback  unmanaged    --       

Oepsie… opdracht hergebruikt, maar slechts deels aangepast (Warning: there is another connection with the name 'bond0-port1'). Bij de eerste poging om de poort uit bond0 te trekken, heb ik de volledige bond verwijderd. Na opnieuw toevoegen is de status nu:

# nmcli device status
DEVICE   TYPE      STATE        CONNECTION  
nm-bond  bond      connected    bond0       
eno1     ethernet  connected    bond0-port1 
eno2     ethernet  connected    bond0-port2 
eno3     ethernet  unavailable  --          
eno4     ethernet  unavailable  --          
lo       loopback  unmanaged    --          

Losse todo’s:

  • SSH sleutels kopieren – het wordt afgeraden om dezelfde sleutels op meerdere systemen te gebruiken, maar hier wordt het oude systeem uit de vaart gehaald. Na overzetten van het private/public keypair werken de SSH-verbindingen meteen weer.
  • Toegang tot seriele interfaces, zoals /dev/ttyACM0 voor Arduino, ESP of toetsenbord
  • Blogpost nalopen op slordigheden en bijwerken met de laatste inzichten; eerst maar uit concept halen om er makkelijk bij te kunnen. Bij deze!

Print this entry

LVM cache aan bestaande LVM RAID1 mirror toevoegen

Een nieuwe HP Microserver gen8 is ingericht met Proxmox.

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

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

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

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

Uit te voeren stappen:

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

Dat is alles. Bekijk het resultaat met lvs mt_usbsdraid:

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

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

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

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

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

Print this entry

Containers met internet, maar Proxmox zonder

Het lukte niet meer om Proxmox de upgraden. Het bleek dat er geen internettoegang meer was. Specifieker: het hele lan, behalve de (interne kant) router was bereikbaar. Bij nader onderzoek bleek PBS, de backupserver, hetzelfde probleem te hebben.

Het lukte ook niet om vanaf de router die twee machines te bereiken. Ondertussen werkten de containers gewoon en waren bereikbaar vanaf internet, en konden er ook gewoon backups verstuurd worden.

Na toch wel een tijdje puzzelen met DNS, DHCP/statisch, bonds en bridges, kwam ARP in beeld als boosdoener. arping gaf niet thuis op het IP dat ik voor ogen had, en gaf een incorrect MAC bij een IP wat wel een reactie gaf.

De oorzaak zat er in dat ik voor enkele hosts een statische MAC/IP koppeling in de ARP-tabel van OPNSense had laten vastleggen, met het idee de MAC-adressen niet uit het hoofd te hoeven leren voor wake-on-lan.

De boosdoener: een statisch ARP record

Na uitvinken van de vinkjes, toepassen van de wijzigingen en leeggooien van de ARP-tabel, werkte het weer!

Print this entry

IPv6 – nogmaals

Vorige week heb ik – eindelijk – een laadpaal geinstalleerd ter vervanging van de kabel die al ruim 6 jaar uit het zolderraam hing te bungelen. Voordat de stroom er af ging, heb ik alle apparatuur in het zicht netjes uitgeschakeld, maar de server staat niet in het zicht en kwam niet meer online toen er weer stroom was.

Zodra ik dat door had, kon ik met een handmatige ingrepen het gros weer draaiend krijgen, voor het moment, maar na een blikseminslag vandaag was de stroom er opnieuw vanaf met hetzelfde resultaat: website en webservices off-line.

Iets wat zowiezo nog niet goed werkte, en nu dus zeker niet, was het betrouwbaar uitdelen van IPv6-adressen in het netwerk. Daarbij kwam nu dat IPv4 niet goed terechtkwam.

In de logging van OPNsense viel me op dat er regelmatig no route to host gemeld werd:

<187>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="5"] send_packet6: No route to host

Daar had ik eerder nog niet naar gezocht, of niet op de juiste zoekresultaten geklikt. Deze keer klikte ik een link naar het Netgate forum, waar met name een post er uitsprong. Het relevante deel:

I added to the bridge a link local IPv6 address … Soon after the DHCP log started indicating the DHCP response completed successfully

wallabybob

Ik controleerde de configuratie van de bridge op de router; er was wel een IPv6-adres aan toegekend, maar geen local link adres. Bovenstaand citaat is uit 2011, ruim 12 jaar geleden. Ik kon bijna niet geloven dat ik nu nog steeds tegen dat probleem aan kon lopen, maar na lezen (en leren) van de rest van de thread heb ik het toch geprobeerd:

# ifconfig bridge0 inet6 add fe80::5a9c:fcff:fe10:ff91/64

Geloof het of niet, maar direct daarna verdwenen de no route to host’s , en verschenen daarvoor in de plaats Reply NA‘s; zie de stukjes log, als eerste de fouten:

<190>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="1"] Solicit message from fe80::dab6:b7ff:feb7:981a port 546, transaction ID 0x577C2900
<191>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="2"] Picking pool address 2a10:3781:2d49:172:26:90:0:f525
<190>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="3"] Advertise NA: address 2a10:3781:2d49:172:26:90:0:f525 to client with duid 00:03:00:01:d8:b6:b7:b7:98:1a iaid = -1212704742 valid for 7200 seconds
<190>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="4"] Sending Advertise to fe80::dab6:b7ff:feb7:981a port 546
<187>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="5"] send_packet6: No route to host
<187>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="6"] dhcpv6: send_packet6() sent -1 of 104 bytes
<190>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="7"] Solicit message from fe80::225:61ff:fee3:1ee0 port 546, transaction ID 0xFB62AD00
<191>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="8"] Picking pool address 2a10:3781:2d49:172:26:90:0:f79c
<190>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="9"] Advertise NA: address 2a10:3781:2d49:172:26:90:0:f79c to client with duid 00:03:00:01:00:25:61:e3:1e:e0 iaid = 2424874 valid for 7200 seconds
<190>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="10"] Sending Advertise to fe80::225:61ff:fee3:1ee0 port 546
<187>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="11"] send_packet6: No route to host
<187>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="12"] dhcpv6: send_packet6() sent -1 of 100 bytes
<190>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="13"] Information-request message from fe80::ec4:7aff:fec1:25e4 port 546, transaction ID 0x7A418D00
<190>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="14"] Sending Reply to fe80::ec4:7aff:fec1:25e4 port 546
<187>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="15"] send_packet6: No route to host
<187>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="16"] dhcpv6: send_packet6() sent -1 of 73 bytes

… daarna de correcte verwerking:

<190>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="19"] Solicit message from fe80::dab6:b7ff:feb7:981a port 546, transaction ID 0x577C2900
<191>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="20"] Picking pool address 2a10:3781:2d49:172:26:90:0:f525
<190>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="21"] Advertise NA: address 2a10:3781:2d49:172:26:90:0:f525 to client with duid 00:03:00:01:d8:b6:b7:b7:98:1a iaid = -1212704742 valid for 7200 seconds
<190>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="22"] Sending Advertise to fe80::dab6:b7ff:feb7:981a port 546
<190>1 2023-07-09T21:57:08+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="133"] Reply NA: address 2a10:3781:2d49:172:26:90:0:f525 to client with duid 00:03:00:01:d8:b6:b7:b7:98:1a iaid = -1212704742 valid for 7200 seconds

Ik ben er nog niet uit hoe het met de volgordelijkheid zit: eerder liepen de meta sequence id’s slechts tot ergens in de 20, nu ver voorbij 100. Nummers <190> en <191> lijken OK, de eerdere fouten vallen onder <187>.

Het resultaat is nu dat opeens heel veel apparaten een IPv6 toegewezen hebben gekregen. Waar ik er eerst met hangen en wuren twee of drie kreeg, instabiel (telkens andere IP’s, telkens andere apparaten), is er nu opeens een hele lijst.

Nog te doen: herkenbare statische leases aanmaken voor vaste apparatuur, en natuurlijk waar het om begon: zorgen dat de webserver een IP krijgt tijdens boot.

Print this entry

Firefox sync server

Omdat de sync server afhankelijk is van Python 2, is het al een tijdje lastig de boel bij te werken. De syncserver op online.osba.nl houdt daarmee de volledige server in z’n grip, omdat daardoor Debian niet van 10 naar 11 geupgrade kan worden. Daarmee zijn recente PHP-versies niet goed beschikbaar, waardoor andere pakketten weer niet bijgewerkt kunnen worden.

De sync server krijgt daarom een eigen machine toegewezen. Het adres veranderd helaas een klein beetje, wat weer gevolgen heeft voor alle verbonden Firefox instanties. Op desktopversies is dat nog wel makkelijk aangepast via about:config, maar op Android is die pagina sinds een paar versies niet meer beschikbaar.

Er is een wat spijtige workaround voor Firefox op Android nodig:

  • ga naar settings –> about Firefox –> klik 5x op het Firefox-logo.
  • er volgt een popupje dat debug-settings beschikbaar zijn
  • in settings is nu onder het kopje ‘Account’ een menu-optie ‘Custom Sync Server’ beschikbaar gekomen.
    • Zolang er een reeds verbonden Firefox-account actief is, is de optie uitgegrijsd
  • vul als custom sync server in: https://ffs.osba.nl/ffsync/token/1.0/sync/1.5
  • Als je het veld leegmaakt, wordt de hele optie op nul gezet en moet je opnieuw op het logo kloppen.

Op dezelfde pagina is te lezen dat voor desktop-versies van Firefox de custom-synchronisatie-optie ook moeilijker gemaakt is, naast het invullen van de URL van de synchronisatieserver, was het ook nodig twee andere instellingen op nee te zetten:

  • identity.fxaccounts.useSessionTokensForOAuth = false
  • identity.sync.useOAuthForSyncToken = false
  • de tokenserver zelf nog steeds corrigeren naar de eigen server:
    • identity.sync.tokenserver.uri = https://ffs.osba.nl/ffsync/token/1.0/sync/1.5

Print this entry

Yunohost SSH toegang

Normaliter hebben Yunohost-gebruikers geen SSH-toegang. Zodoende is het lastig om de bestanden via SSHFS te benaderen. Om de bestanden via SSHFS te benaderen, zijn er twee dingen aan te passen.

  1. SSH toegang beschikbaar maken voor de gebruiker
  2. Toegang op bestandsniveau regelen voor die gebruiker via ACL

1 – SSH toegang

Via het Yunohost forum werd ik gewezen op de SSH-toegang die vanaf (ongeveer) versie 4.2 van Yunohost uitgedeeld kan worden. Ik gebruik voor SSH toegang een afzonderlijke gebruiker, die naast SSH-toegang, geen applicaties toegewezen krijgt.

Gebruiker voor SSH toegang

Via ‘Manage groups and permissions’ kun je SSH-toegang toewijzen:

Maak een nieuwe groep (hier sshfsnc), en geef die SSH-permissie
Voeg de gebruiker die je net gemaakt hebt toe aan de SSH-groep

2 – ACL’s

Via access control lists kun je extra rechten toekennen aan bestanden, naast de reguliere eigenaar/groep/iedereen rechten op bestandsniveau.

De toegangsrechten van Yunohost zijn erg nauw gedefinieerd. Via het bestandssysteem kun je als gebruiker niet bij je eigen bestanden die in Nextcloud staan, en Nexctloud kan niet bij je bestanden in je home-directory. De admin-gebruiker kan ook maar beperkt bij verschillende bestanden komen, alleen root kan overal bij.

Om via de gebruiker met SSH toegang de bestanden uit Nextcloud te benaderen, moeten die vrijgegeven worden via ACL. Hoe dat gaat, heb ik in dezelfde forumthread gepost:

# cd /home/yunohost.app/nexctloud/data/
# setfacl -Rm u:boudewijn_ssh:rx boudewijn/
# setfacl -dRm u:boudewijn_ssh:rx boudewijn/
# setfacl -m u:boudewijn_ssh:rx .
# setfacl -dm u:boudewijn_ssh:rx .

Er is telkens een regel voor de nieuwe default (met -d), en dezelfde voor de rechten op de bestaande bestanden. Daarnaast telkens een recursieve regel (-R) voor de data-directory van gebruiker boudewijn, en een niet-recursieve op de huidige directory (/home/yunohost.app/nextcloud/data/). Setfacl heeft -m nodig, daarmee geef je aan dat het een wijziging/modificatie is.

Synchronisatie

Zolang je via SSHFS enkel bestanden leest, blijft alles werken zoals vanouds. Als je ook bestanden wegschrijft via SSHFS, loopt die actie buiten Nextcloud om. Het bestand wordt daardoor niet in Nextcloud geregistreerd, en is daarvandaan niet zichtbaar. Er is een OCC-opdracht om de opslagruimte te scannen op wijzigingen en de database bij te werken.

WebDAV

Om het toevoegen van bestanden, en alle wijzigingen aan bestanden, meteen in Nextcloud beschikbaar te maken, moet de verbinding via WebDAV gemaakt worden. Het werkt minder snel, maar wordt op meer platformen ondersteund dan SSHFS.

Print this entry

Schijfmigratie met LVM – huidige/doel-indeling

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

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

De huidige inrichting, wat fysieke schijven betreft:

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

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

NAS/Mediaserver

De huidige inrichting in meer detail is:

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

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

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

De nieuwe inrichting wordt:

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

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

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

Waar blijft de opslagruimte

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

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

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

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

Caching

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

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

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

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

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

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

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

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

RAID

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

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

OverlayFS

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

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

Thin provisioning

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

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

Documentatie en voorbeelden heb ik in blogs gevonden:

Trim

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

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

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

Ook aan denken

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

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

Algemene LVM links

LVM internals
Development/LVM support

Stappenplan

PMR-schijf indelen

Welke data waar

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

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

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

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

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

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

Methode

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

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

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

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

Stap 1, partitionering

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

Stap 2, Fysiek volume aanmaken en toewijzen aan volumegroep

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

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

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

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

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

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

lvresize -rvL -5G /dev/data/geluid
Executing: /sbin/fsadm --verbose check /dev/data/geluid
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluid".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-geluid
fsck from util-linux 2.33.1
geluid: 7763/3055616 files (1.1% non-contiguous), 10199026/12206080 blocks
Executing: /sbin/fsadm --verbose resize /dev/data/geluid 43581440K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluid".
fsadm: Device "/dev/mapper/data-geluid" size is 49996103680 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluid"
fsadm: Resizing filesystem on device "/dev/mapper/data-geluid" to 44627394560 bytes (12206080 -> 10895360 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-geluid 10895360
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-geluid to 10895360 (4k) blocks.
The filesystem on /dev/mapper/data-geluid is now 10895360 (4k) blocks long.
Archiving volume group "data" metadata (seqno 17). Reducing logical volume data/geluid to 41.56 GiB
Size of logical volume data/geluid changed from 46.56 GiB (11920 extents) to 41.56 GiB (10640 extents).
Loading table for data-geluid (253:4).
Suspending data-geluid (253:4) with device flush
Resuming data-geluid (253:4).
Creating volume group backup "/etc/lvm/backup/data" (seqno 18).
Logical volume data/geluid successfully resized.
# # spiegelen instellen; default type=raid
# # lvconvert --type raid1 /dev/data/fotos
# # bij m1 wordt er 1 kopie gemaakt, dus op
# # de nieuw toegevoegde PV
# # lvconvert -m1 /dev/data/fotos
# # samengesteld commando:
# lvconvert -m1 /dev/data/fots /dev/sdf1
Are you sure you want to convert linear LV data/fotos to raid1 with 2 images enhancing resilience? [y/n]: yes
Logical volume data/fotos successfully converted.

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

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

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

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

Het juiste commando blijkt niet iotop, maar iostat:

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

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

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

Volgende LV: geluid. Op dezelfde manier:

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

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

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

Vervolg-spiegelacties:

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

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

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

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

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

Ik denk dat de juiste manier is:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aansluitend spiegelen:

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

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

Slitsen lukt niet direct:

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

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

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

Ok, dat is niet de oplossing:

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

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

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

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

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

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

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

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

Aansluitend:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Cache inrichten

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

Voor de system-VG heb ik voor ogen:

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

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

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

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

Daarna de sync voor var, usr en varlog aanzetten:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Losse eindjes

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

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

Eerst de data van /home/ssdata verplaatsen:

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

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

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

Huishoudelijk: disk repartitioneren tot:

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

Toewijzing aan VG’s gaf een opvallende waarschuwing:

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

Verder niets noemenswaardigs bij het toewijzen:

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

Tussentijdse conclusies en overwegingen

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

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

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

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

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

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

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

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

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

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

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

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

“De volgende dag…”

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

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

Twee opties, naast het erbij laten:

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

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

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

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

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

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

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

Ja, het juiste PV is verdwenen.

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

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

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

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

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

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

so far… so good.

Data VG fatsoeneren

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

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

Print this entry

LVM: thin snapshot with external origin

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

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

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

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

Als eerste test de partitie met video’s.

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

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

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

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

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

Aansluitend ‘voor het echie’, ook OK:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

… een reboot later …

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

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

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

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

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

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

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

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

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

Constateringen:

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

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

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

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

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

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

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

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

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

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

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

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

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

  • fotos
  • muziekNR
  • pubNR
  • rom
  • video

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

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

Voor publiek toegankelijke LV pubNR:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Het meeste is nu gebeurt. Nog te doen:

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

Print this entry

Nextcloud fout bij upgrade: 1118 row size too large

Geen idee meer bij welke upgrade het speelde (NC18 naar NC20?), maar:

An exception occurred while executing 'ALTER TABLE oc_social_3_stream ADD nid BIGINT UNSIGNED DEFAULT NULL, ADD chunk SMALLINT UNSIGNED DEFAULT 1 NOT NULL': SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs 

opgelost met:

su mysql 
mysql 
show databases; 
use nextcloud;
show columns from  oc_social_3_stream;


exit ;


cd /var/www/nextcloud/
 chmod +x occ
sudo -u nextcloud ./occ maintenance:repair

Print this entry

Schijfmigratie met LVM – wat hoort waar

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

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

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

De schijven die ik beschikbaar heb, zijn:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Partition table entries are not in disk order.

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

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

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

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

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

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

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

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

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

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

Print this entry