Berichten

Geplaatst op

WordPress layout te smal, welke CSS?

WordPress is leuk en aardig, en je hebt er snel een strakke start voor een website mee. Tegenover zelf de volledige pagina’s voor je site schrijven vind ik het nadeel, dat er van alles op de pagina staat, en op plaatsen op de pagina, waar je zelf niet direct iets voor gedaan hebt. Als het dan niet is wat je wil, is het lastiger om het aan te passen.

De breedte van de tekst was me al sinds het begin een doorn in het oog. Schermen van 640×480 pixels gaven me altijd een claustrofobisch gevoel. Tegenwoordig heeft iedereen grotere schermen dan dat, waarom staan er dan maar zeven woorden op een regel op de gemiddelde webpagina? Maak je browservenster breder, en je hebt zeeen van witruimte links en rechts.

Dus, in ieder geval voor m’n eigen site: op zoek naar een oplossing. Een paar WordPress-thema’s geprobeerd, allemaal met zo’n stomme smalle kolom voor de tekst. Een paar zoekopdrachten geeft vooral resultaten van mensen die klagen over de breedte van de Gutenberg-editor en de blok-inrichting voor het schrijven van blogposts, maar slechts enkele over de breedte van de resulterende paginatekst.

Het zou mogelijk moeten zijn om onder Appearance/Customize/Layout de breedte aan te passen, maar bij mij mist de optie.

Voor de paar mensen die met datzelfde probleem als zoekresultaat terugkomen, willen ze net iets anders aanpassen en wordt er een specifieke oplossing voor dat eiland-probleem gegeven, of er wordt geconstateerd (door iemand anders) dat het nu blijkbaar werkt maar zonder terugkoppeling van de oorspronkelijke poster wat er veranderd is.

Een andere optie is om ‘Additional CSS’ te gebruiken. De meeste specifieke oplossingen vallen daarop terug, en waarschuwen dat het _alleen_ voor dat specifieke thema werkt. Hoe pas je het dan toe op een ander thema? Met wat zoekwerk in ‘inspect element’ van je browser:

Dan is het een beetje rondklikken om stukken te highlighten in het inspectievenster en te vergelijken met de arcering op de pagina. Het viel me op dat onder ‘Box Model’ het verschil in breedte tussen <div id=”content” class=”site-content”> en <div class=”wrap”> erg groot was: bij de eerste 1460px breedt, daarna nog maar 892px+2x54px.

Klasse site-content heeft een breedte van 1460 pixels
Klasse wrap heeft een breedte van maximaal max-width=1000px. In die div zitten de blog-text en het menu aan de zijkant; van de 1000 pixels gaat de padding nog af waardoor er gezien de breedte van het menu, maar zo’n 4-500 pixels voor de tekst overblijven.

De klasse .wrap heeft een max-width van 1000px, dat is precies de som van het box model.

Dat stukje in het het inspectievenster heb ik aangepast naar max-width=100% om live te zien wat het effect is, en het daarna in het “additional CSS” schermpje geplakt:

.wrap {
	max-width: 100%;
}

Na publiceren ziet het er een stuk breder uit, en kan ik de tekst opgelucht lezen:

Het menu gebruikt nog steeds 1/3e van de breedte, daar kom ik voorlopig wel overheen.

Print this entry

Geplaatst op

Statisch WordPress archief

De site van klas6musical.nl wordt telkens korte tijd bewoond door de zesde klas, en een paar maanden na het eind van het schooljaar leeggemaakt voor de volgende klas.

Bij de eerste versie heb ik aangeboden een statische kopie te maken als aandenken. Na een paar keer mijn tanden stukgebeten te hebben op de conversie van dynamische WordPress-site naar statisch archief van HTML-pagina’s en toebehoren, is het een tijd blijven liggen. Nu is het toch bijna afgerond.

Wat moest er gebeuren:

  • Homepagina downloaden
  • recursief de links volgen
  • Pagina’s en multimedia-inhoud downloaden

Voor het downloaden heb ik HTTrack gebruikt. Na wat testen heb ik een bruikbaar archief met deze opdrachtregel: 

httraqt -q -%i -i https://www.klas6musical.nl/ -r8 -%e1 -C2 -t -%P -n -s2 -z -%s -%u -N0 -p7 -D -a -K0 -m0,0 -c8 -%k -f2 -A0 -F "Mozilla/5.0 (X11; U; Linux i686; I; rv:33.0) Gecko/20100101 Firefox/33.0" -%F "<!-- Mirrored from %s%s by HTTraQt Website Copier/1.x [Karbofos 2012-2017] %s -->" -%l ua,en -O /home/wbk/tmp/webarchives/klas6musical/ +*.png +*.gif +*.jpg +*.css +*.js -ad.doubleclick.net/*

Er zit een GUI (QT, zodoende httraqt) bij waarmee je de boel kunt tunen. Ik weet de betekenis van alle switches niet meer. De eerste -r8 is het aantal recursies; het stukje ‘Mozilla…’ is hoe/als welke browser HTTrack zich voordoet. Met -O wordt de locatie opgegeven waar alles opgeslagen wordt; de +’jes geven de bestandstypen die wel gedownload moeten worden, naast HTML, de -‘etjes wat er niet gevolgd moet worden (beperkt tot een advertentienetwerk, met doubleclick werd het archief overspoeld).

Het resultaat: 8000 bestandjes, verdeeld over 5000 directories, totaal anderhalve GB aan data. Klaar!

Klaar? Nee, helaas. Elke directorie is een website waar iets van gedownload is. Vijfduizend websites dus. Van de 5000 directories zijn er maar een stuk of 20 waar we in geinteresseerd zijn. Alle (overige) advertentienetwerken, 20xInstagram, 200xFacebook, 1000x content delivery networks, 2000x Google sites, allerlei overige sites.

Na flink snoeien, is dit wat er over is:

Het gaat vooral om www.klas6musical.nl, natuurlijk.

Opruimen is wel netjes natuurlijk, en scheelt later een hoop tijd (kopieren naar USB-stik kostte ~4 uur…) maar als alles al werkte zou ik daar waarschijnlijk minder aandacht aan besteed hebben. Maar alles werkte nog niet.

Dit moest gerepareerd worden :

  • Plaatjes op de site waren gedownload, maar werden niet getoond
  • Filmpjes werden wel getoond, maar waren niet gedownload.

De plaatjes zagen er zo uit:

(todo, copy/paste screenshot)

De oorzaak zit in de opbouw van de pagina. Er wordt voor verschillende schermformaten een mooie lijst met plaatjes gereserveerd. Na het downloaden als statische bestanden in verschillende directories zorgt dat het niet meer werkt. Misschien beveiliging van de browser, die voorkomt dat een webpagina gegevens van willekeurige directories kan lezen, of een HTML-stuurcode die niet goed werkt met locale bestanden.

Na wat uitproberen, heb ik gevonden hoe ik de gallerij-functionaliteit op genuanceerde wijze kapot kan maken door een HTML-tag te vervangen. Oorspronkelijk stond er een srcset; dat werkte niet. Comment leek me ook wel eens geen fout te kunnen geven. Dat werkte! Daarna voor alle bestanden vervangen: 

grep -rl srcset .|grep html |xargs sed -i 's/srcset/comment/g'

Alle plaatjes worden nu getoond. De link is echt stuk, dus inzoomen is er niet bij, maar als het nodig is kun je de foto gewoon ‘los’ openen.

Dan de filmpjes. Op het moment staan ze nog op Youtube, de meeste, maar je weet niet hoe lang het blijft staan. En ze staan niet in het archief, terwijl dat juist het idee was. Youtube-dl to the rescue.

Youtube-dl geef je een link van Youtube, en youtube-dl verzameld alle stukjes film en maakt er een complete film van. Daarvoor heb je wel alle Youtube-links van de hele site nodig.

Alle Youtube-links blijken in de www.youtube.com/embed-directorie te staan. De links naar alle filmpjes heb ik verzameld door: 

# Ga naar de juiste directorie,
# cd /home/wbk/tmp/webarchives/www.klas6musical.nl/www.youtube.com/embed
# Verzamel _alle_ links:
# cat --  *html |grep 'Mirrored from ' >> links.txt

Het bestandje links.txt heeft nu alle links, maar wel met wat rommel er omheen. Die rommel is elke keer hetzelfde, en is met zoeken en vervangen snel weg. 

# Door de opbouw van de HTML-bestanden heb ik nu alles dubbel. Sort kan ontdubbelen: 
# sort -u links.txt > links_uniek.txt

Het resulterende bestandje is een lijst met kale links die er uitzien als https://youtu.be/Mmqn7xp8kIM ; die voer ik aan youtube-dl die ze download naar de ‘huidige’ directory, films: 

# cd /home/wbk/tmp/webarchives/www.klas6musical.nl/www.klas6musical.nl/films
# youtube-dl -a links_uniek.txt

Youtube-dl geeft standaard als naam de titel van de video + de code in de link. Die code ziet er niet mooi uit, maar die heb ik nodig om het bestand weer te kunnen koppelen in de site zelf.

Elke pagina waar een film op voorkomt, bestaat uit de pagina zelf en een ‘bakje’ (“div”) waar een Youtube-pagina uit de youtube.com/embed directory in zit. Die Youtube-pagina is tig A4’tjes aan tekst groot, en bestaat onder andere uit een videospeler en een verwijzing naar de locatie bij Google waar de film opgeslagen is.

Een heeeeleboel lettertjes. Als je goed kijkt, staat er rechtsonderin ‘etc…’

Maar die willen we dus niet gebruiken. Zelfde techniek als bij de niet getoonde plaatjes: een botte bijl en een paar keer proberen. De duizenden regels code vervang ik door vier regels tekst die proberen de video te laden vanuit het archief:

Dat is alles!

Bij het koppelen gaat het om de geselecteerde tekst, dat is de naam van het videobestand. Sommige gaan niet goed: een naam die begint met ‘#’ werkt niet, video’s van het type .mkv kan de browser vaak niet rechtstreeks tonen. Dat betekent naam veranderen (bij #) of een link in plaats van een embedded video maken (met <a href=’../../het/zelfde/pad.mkv’>mooie naam</a>).

Voor het gemakkelijk kopieren/plakken: 

<div id="videoDiv">
     <video id="video" src="../../www.klas6musical.nl/films/Aflevering 11 vervolg Telefoongesprek-6zJbLWTppmc.mp4" width="70%" controls>
</div>
    
<!--End  videoDiv-->

Er zijn zo’n 250 bestanden in de youtebe.com/embed-directory, maar een redelijk deel ervan blijkt nog naar advertenties de linken: weg ermee.

Samengevat:

  • Site downloaden met
    • httraqt -q -%i -i https://www.klas6musical.nl/ -r8 -%e1 -C2 -t -%P -n -s2 -z -%s -%u -N0 -p7 -D -a -K0 -m0,0 -c8 -%k -f2 -A0 -F “Mozilla/5.0 (X11; U; Linux i686; I; rv:33.0) Gecko/20100101 Firefox/33.0” -%F “” -%l ua,en -O /home/wbk/tmp/webarchives/klas6musical/ +.png +.gif +.jpg +.css +.js -ad.doubleclick.net/
  • Gallerij ‘repareren’ door op de hoofd-directory:
    • grep -rl srcset .|grep html |xargs sed -i ‘s/srcset/comment/g’
  • Filmpjes downloaden met youtube-dl
  • Linkjes naar de filmpjes corrigeren

Print this entry

Geplaatst op

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

Geplaatst op

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

Geplaatst op

HP Photosmart D7160 0x18a0001 – ink system

Met de beschrijving op https://h30434.www3.hp.com/t5/Printing-Errors-or-Lights-Stuck-Print-Jobs/Ink-system-failed-Error-Oxc18a0101-on-photosmart-D7160/m-p/27071#M231430

Fix your HP Photosmart D7360 (Reset Code/Master Reset)

1- Turn off power and unplug from power source.
2- Open right side of printer (looking at the front).
3- Disconnect,by pulling gently, both white flat ribbon cables off the main circuit board.
4- Plug in power source and turn printer on. Wait till you get a error message and push “Ok”.
5- Unplug power source.
6- Reconnect the flat ribbon cables by aligning and carefully pushing into the conectors on the main circuit board.
7- Plug in power source and turn printer on (Printer preparing occurred).
8- voila, the nasty error message 0xc18a0001 “Ink System has Failed” is now gone. http://www.fixya.com/support/t451942-help    THIS WORKED!!!  Don’t throw it out try this first for: Ink system failed Error:Oxc18a0101 on photosmart D7160. 

Het is best lastig de zijkant te verwijderen. Er zitten een paar schroeven in, en na het verwijderen van de schroeven zitten er weerhaakjes voor eenmalig vastzetten en niet meer losmaken. Door met beleid kracht toe te passen, is de zijkant te verwijderen zonder al te veel clips af te breken.

Een andere optie vond ik op http://www.ccl-la.com/blog/index.php/hp-photosmart-ink-system-failure-2

HP PhotoSmart “Ink System Failure” #2

January 20, 2010 by CCL_TECH
Filed under: Uncategorized 

For HP PhotoSmart and Deskjet printers without Fax capabilities, use this guide.
Are you experiencing the ink system failure on your printer? The error is
caused by air getting in the ink tubes feeding the system. This is normally
cause by refilled cartridges but can be caused by any cartridge that goes very
low on ink and then tries to reload ink. This reset procedure does have to be
performed with a full cartridge installed. The following reset procedure will
correct the issue by purging the ink tubes and flushing any air trapped in them.

This sequence works if you have a C3110, C3210 or C3310 series printer. This
reset procedure should also work on any printer without FAX capabilities.
 
Please perform the following steps in order:
1. Make sure you have new cartridges in the printer so that it can reset
2. Press down the OK and Cancel buttons down at the same time and turn the
printer
off.
3. Keep holding the buttons down until the printer turns off.
4. Release the buttons.
5. Now turn the printer on while pressing the OK and Cancel buttons. It should cycle a bit then
turn back off.
6. Turn the unit on again.
7. After the second time off/on the printer will recalibrate the ink cartridges,
this will take about 5 minutes.
8. After calibration it should be online ready to print. Print a test page to
verify operation.

You should be back up and running. If this procedure does not solve the problem
then remove the cover from the printer and check the small white gear on the end
of the ink pump. The gear can come off after heavy use, just push it back on and
then redo the reset precedure as described above.


Print this entry

Geplaatst op

Proxmox op Debian

Proxmox biedt een ‘bare metal’ installer, waarmee automatisch het hele systeem klaargezet wordt. Mijn eerste Proxmox-server heb ik op die manier geinstalleerd.

Voor de huidige server zou ZFS een goede keuze kunnen zijn, maar met slechts 4GB aan RAM is het al wat krap voor alleen Proxmox en enkele containers. ZFS staat er om bekend beter te werken als het zwemt in beschikbaar geheugen, omdat ik dat onvoldoende kan inschatten wil ik voor deze installatie geen ZFS gebruiken.

‘Geen ZFS’ betekent ‘geen kant-en-klare’ installer. Gelukkig is het niet heel veel werk om een standaard Debian-installatie uit te breiden met Proxmox. De kale Debian installatie zat rond 100MB geheugengebruik. Ik volg een stappenplan van de Proxmox-website. In grote lijnen:

  • Machine in elkaar zetten
  • Debian installeren.
  • Afhankelijkheden in inrichting goedzetten:
    • /etc/hosts aanpassen om het externe IP terug te geven
    • /etc/apt/sources* uitbreiden met de repositories van Proxmox
  • Proxmox installeren met apt install proxmox-ve postfix open-iscsi
    • De download is ~350MB, installatie voegt ~1800MB toe.
  • Klaar!
    • Nog te doen: rechten instellen, containers maken, systeem gebruiken
# df -hTt ext4
Filesystem                   Type  Size  Used Avail Use% Mounted on
/dev/mapper/snelsys-root     ext4  2.7G   13M  2.6G   1% /
/dev/mapper/snelsys-usr      ext4  7.3G  1.1G  5.9G  15% /usr
/dev/sde2                    ext4  163M   83M   68M  55% /boot
/dev/mapper/slowsys-var      ext4  2.7G  153M  2.4G   6% /var
/dev/mapper/slowsys-varcache ext4  1.8G   77M  1.7G   5% /var/cache
/dev/mapper/slowsys-varlog   ext4  1.8G   24M  1.7G   2% /var/log
root@thuis:~# apt install proxmox-ve postfix open-iscsi
0 upgraded, 494 newly installed, 1 to remove and 0 not upgraded.
Need to get 342 MB of archives.
After this operation, 1,742 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Het liep fout; er was niet voldoende ruimte op /boot. Op de andere server is er 800MB in gebruik voor ‘tig’ kernels, dat leek me wat overdreven. Hier zijn het er drie, daarvan kan er op zijn minst eentje per direct weg. 

# dpkg -l | grep linux-image | awk '{print$2}'
linux-image-4.19.0-13-amd64
linux-image-4.19.0-6-amd64
linux-image-amd64
root@thuis:~# uname -a
Linux thuis 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
# apt remove --purge linux-image-4.19.0-6-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-image-4.19.0-6-amd64*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 269 MB disk space will be freed.
Do you want to continue? [Y/n] 
...
update-initramfs: Deleting /boot/initrd.img-4.19.0-6-amd64
/etc/kernel/postrm.d/zz-pve-efiboot:
Re-executing '/etc/kernel/postrm.d/zz-pve-efiboot' in new private mount namespace..
No /etc/kernel/pve-efiboot-uuids found, skipping ESP sync.
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
...
update-initramfs: Generating /boot/initrd.img-5.4.78-2-pve
Running hook script 'zz-pve-efiboot'..
Re-executing '/etc/kernel/postinst.d/zz-pve-efiboot' in new private mount namespace..
No /etc/kernel/pve-efiboot-uuids found, skipping ESP sync.
#

Op / is er nauwelijks wat geinstalleerd, het iz vooral /usr waar ~1500MB aan toegevoegd is (1200 netto verschil, na purge oude kernel).

Rechten toewijzen

De Proxmox-installer maakt geen gebruikers aan. De Debian-installer wel. Bovendien heb laat ik de Debian-installer root-login uitschakelen. Zodoende is de bestaande gebruiker geen gebruiker die toegang tot Proxmox heeft.

Om Proxmox via de web-interface te bedienen, moet de gebruiker ingericht worden:

# pveum user add ikzelf@pam
# pveum groupadd beheer -comment "Proxmox en containers instellen"
# pveum aclmod / -group beheer -role Administrator
# pveum usermod ikzelf@pam -group beheer

De nieuwe rechten worden on-the-fly toegekend, maar bij het switchen tussen niveau’s op de web-interface komen maar enkele knoppen beschikbaar als je al ingelogd was voordat je aan de groep met ‘Administrator’-rol toegevoegd bent. Het was daarvoor in mijn geval niet voldoende uit- en in te loggen, of de pagina te verversen. De nieuwe eigenschappen werden pas zichtbaar na uitloggen, tab sluiten en inloggen in een nieuw tab.

Gegevensruimte / opslag

De servers heeft vier fysieke opslagmedia:

  • 1x SSD /dev/sde, 80GB
    • 9M BIOS boot, GPT-partitie voor GRUB
    • 170M /boot
    • 5.6G swap
    • 13G LVM PV
      • 13G VG ‘snelsys’
        • 2.8G LV root
        • 7.5G LV usr
    • 56G vrije ruimte
      • 3G ‘overprovisioning’, om de firmware ruimte te geven verwijderde bestanden op bestandssysteem-niveau, via LVM-pass-through als fysieke toewijzingen, de als leeg gemarkeerde sectoren te wissen. Als het goed is past de SSD-firmware dynamische wear-leveling toe, zodat die 3G vrije ruimte nomadisch over de flash-cellen rondwaart.
      • 50G+ voor read/write caching, ongeveer 10G/TB aan HDD-ruimte. Niet veel, maar het scheelt. Waarschijnlijk maak ik een enkele VG uit de twee vrije HDD’s, zodat de caching ineens voor alle LV’s voorbereid is. Misschien 1G voor VG slowsys, zodat alles onder /var SSD-caching heeft.
  • 1x HDD /dev/sda, 2TB, deels gebruikt:
    • 28G LVM PV
      • 28G VG ‘slowsys’
        • 2.8G LV var
        • 1.8G LV varcache
        • 1.8G LV varlog
    • ~2TB vrij, ik denk om een VG voor backups te maken
  • 2x HDD /dev/sdb en /dev/sdc, ieder 2TB, leeg
    • Op beide schijven LVM PV’s van ~450TB, tot 98% van de volledige ruimte
      • Bij sommige LVM-bewerkingen is een paar MB aan vrije ruimte nodig, er is nu 40G per schijf beschikbaar voor noodgevallen.

Schijven inrichten

Zoals beschreven, op iedere schijf partities van 450GB met (in fdisk) type 31 (Linux LVM):

# fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EFRX-68A
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: 2DF239C2-BCE1-674A-ACCA-F6D6C45B5649

Device          Start        End   Sectors   Size Type
/dev/sdb1        2048  951757283 951755236 453.9G Linux LVM
/dev/sdb2   951758848 1903514564 951755717 453.9G Linux LVM
/dev/sdb3  1903515648 2855271850 951756203 453.9G Linux LVM
/dev/sdb4  2855272448 3807029134 951756687 453.9G Linux LVM

In de eerste instantie een enkele partitie aan een VG toekennen

# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
# vgcreate yunohost /dev/sdb1
  Volume group "yunohost" successfully created
# pvesm lvmscan
yunohost
snelsys
slowsys

Nu in de Proxmox GUI, via Datacenter –> Storage –> Add –> LVM

Het is verwarrend dat zowel ID als Volume group leeg en verplicht zijn. Bij ID geef je zelf een naam voor de Proxmox-storage op (yunohost, hier), bij Volume group kies je de LVM VG waar de opslagruimte in terechtkomt. Het resultaat:

ISO’s wil ik op een los volume zetten, maar Proxmox gebruikt LVM-volumes als block-storage; ISO’s moeten kunnen enkel op file-storage opgeslagen worden. Het voorbeeld voor directory-opslag laat zien dat de standaardlocatie /var/lib/vz is, daar staat nu een lijstje lege directories. Ik maak een LV met bestandssysteem, kopieer de data en koppel het op die locatie:

# ls -ls /var/lib/vz
total 20
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 dump
4 drwxr-xr-x 2 root root 4096 Dec  3 18:14 images
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 private
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 snippets
4 drwxr-xr-x 5 root root 4096 Jan  9 19:02 template
# lvcreate -n isosetc -L 4G slowsys
  Logical volume "isosetc" created.
# mkfs.ext4 /dev/mapper/slowsys-isosetc 
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 1048576 4k blocks and 262144 inodes
Filesystem UUID: 020be116-ab3f-474b-b407-a7301e59399c
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 

root@thuis:~# mount /dev/mapper/slowsys-isosetc /mnt/
root@thuis:~# cp -r /var/lib/vz/* /mnt/
# echo '/dev/mapper/slowsys-isosetc /var/lib/vz    ext4 defaults 0 2' >> /etc/fstab 
# touch /mnt/ok
# mount /var/lib/vz
# ls /var/lib/vz
dump  images  lost+found  ok  private  snippets  template
#

Nu kan ik met de ingebouwde template-downloader templates van Proxmox ophalen, bijvoorbeeld Debian 10 (voor het screenshot opnieuw geopend; het template is al te zien in de achtergrond)


Op het samenvattingsscherm voor dit stukje opslag is te zien dat de hoeveelheid vrije ruimte en de hoeveelheid gebruikte ruimte schommelt. Tot het aankoppelen van het nieuwe volume bestonden de totale vrije ruimte en de gebruikte ruimte uit alles op LV var, aangekoppeld op /var. De vrije ruimte neemt toe van 3G (vrij op LV var) tot 4G (de vrije ruimte op LV isosetc). De gebruikte ruimte neemt af van ‘alles op /var, behalve /var/cache en /var/log’ (op hun eigen LV) naar 0, en daarna weer tot halverwege 500MB na het downloaden van het Debian-template.

Netwerk – bridge

Op de andere machine heb ik een Open vSwitch bridge gemaakt. Deze keer probeer ik het met een Linux bidge, die schijnt eenvoudiger te werken, ik gok dat dat minder resourceverbruik betekent.

De machine heeft twee fysieke netwerkpoorten, een er van is aangesoten (enp3s0). Via ‘Create –> Linux Bridge’ heb ik de bridge toegevoegd. Zowel de netwerkkaart zelf als de bridge heb ik op autostart gezet, bij enp3s0 was dat initieel niet actief. Het resultaat in de GUI:

De configuratie kan vanuit de GUI toegepast worden als ifupdown2 beschikbaar is. Vanuit de CLI ziet het resultaat eruit als: 

root@thuis:~# apt install  ifupdown2
Reading package lists... Done
Building dependency tree       
...
dpkg: ifupdown: dependency problems, but removing anyway as you requested:
dpkg: ifenslave: dependency problems, but removing anyway as you requested:
Saved in /etc/network/interfaces.new for hot-apply or next reboot.
root@thuis:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual
# This is an autoconfigured IPv6 interface

iface enp2s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.168.6/24
        gateway 192.168.168.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#even kijken of dat zo werkt, moet later aangepast worden naar correcte IP's

iface vmbr0 inet6 static
        address 2001:985:b79a:1:225:90ff:fe33:1189/128
        gateway 2001:985:b79a:1::

root@thuis:~#

Container toevoegen

Met de blauwe ‘Create CT’-knop voeg je een container toe. Hierboven heb ik aan de voorwaarden om er een aan te kunnen maken voldaan:

  • Template – er is een template beschikbaar

Screenshots van de installatiestappen (todo…):

AKranendonk (www.kranendonk.it)
Een blauwe, vierkante knop met de tekst 'Fotos en andere bestanden delen (Nextcloud)'
Zoek Nextcloud uit en klik erop
Het kleine menu'tje waar je kun kiezen een bestand te upoaden
Bovenaan de pagina, naast ‘All files’ / ‘Alle bestanden’
Drie balletjes en twee lijntjes: delen

Login

Inloggen zou makkelijk moeten gaan: IP via DHCP,de machinenaam heb ik opgegeven, moet via lokale DNS op naam bereikbaar zijn, SSH public key heb ik meegegeven, dus login met root@fakraz zou meteen moeten werken.

Niet dus. IP opzoeken in de GUI geeft geen resultaat, er staat alleen ‘DHCP’. In de router/dhcp-server staat onder het MAC adres van de container het IP van de host. Login via console en via shell in de GUI gaat op twee manieren mis: soms is er geen login-prompt, als hij er wel is dan wordt het wachtwoord niet herkend. Blijkbaar herinner ik me niet goed wat ik ingevuld heb.

Gelukkig kan ik vanuit de host toegang krijgen tot de container, met pct:

root@thuis:~# pct enter 100
root@fakraz:~# passwd
New password: 
Retype new password:

Na een reboot van de container werkt ‘opeens’ de login via public key ook, maar de login via console blijft wisselend. Het wil wel eens een paar minuten duren voordat de login-prompt op het scerm staat, maar als die er eenmaal is, lukt het wel in te loggen.

Installatie Yunohost

Het kan allemaal niet in een keer goed gaan natuurlijk. Yunohost heeft last van een DDoS-aanval, waardoor https://install.yunohost.org niet beschikbaar is. Bij het ophalen van de pagina via web.archive.org kreeg ik een certificaat-fout. Google’s cache was wel beschikbaar, maar daar krijg ik 403, geen toegang, met wget.

Tekst kopieren en in een los installatiebestandje plakken lukt wel.

Bij het uitvoeren komen er veel locale-errors voorbij:

perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory                                                                     
locale: Cannot set LC_MESSAGES to default locale: No such file or directory                                                                  
locale: Cannot set LC_ALL to default locale: No such file or directory

In de container mag dpkg-reconfigure locales niet schrijven naar die locatie, gok ik, want toevoegen van de locale geeft in dpkg dezeldfe fout.

Daarom op de host de locale en_US.UTF-8 toegevoegd (naast en_IE.UTF-8); de installatie start nu en verloopt op de normale manier.

Klaar!

Daarmee draait alles:

  • Debian geinstalleerd
  • Proxmox op Debian geinstalleerd
  • Container met Debian op Proxmox
  • Yunohost op Debian in de container

Het draait, met weliswaar lage belasting op het moment, als een zonnetje. Qua hardware heeft Supermicro 2U Twin3 2015TA-HTRF 8x precies deze configuratie. Op hoofdlijnen:

  • Supermicro X7SPA-H-D525
  • Atom D525, 2 cores / 4 threads@1.8GHz
  • 4GB RAM
  • 80GB SSD
  • 3x 2TB HDD

Print this entry

Geplaatst op

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

Geplaatst op

LVM partitie vergroten en het bestandssysteem mee laten groeien

Op vrijwel alle systemen gebruik ik LVM (LVM2 tegenwoordig) voor het indelen van opslagruimte. Er zijn tegenwoordig allerlei mogelijkheden om flexibel met opslagruimte om te gaan, maar de eenvoudige systemen die ik 1-2-3 kan opnoemen (ZFS, BTRFS), zijn nog niet zo lang beschikbaar voor Linux en heb ik nog maar beperkt gebruikt.

LVM zal op bepaalde punten achterlopen, maar voldoet voor mij prima. In dit geval om een krappe home-directory wat ruimte te geven met lvextend.

Voer de opdracht eerst in testmodus (-t) uit: 

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -tvrL +30G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/fsadm --dry-run --verbose check /dev/data/linh
fsadm: "ext4" filesystem found on "/dev/mapper/data-linh".
fsadm: Skipping filesystem check for device "/dev/mapper/data-linh" as the filesystem is mounted on /home/linh
/sbin/fsadm failed: 3
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 274424922112 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 74862592

Let op ‘/sbin/fsadm failed: 3’, omdat het bestandssysteem aangekoppeld is:

root@linhovo:~# umount /home/linh

Voer de opdracht nu uit zonder -t, om de wijziging aan de logische partitie feitelijk door te voeren en het bestandssysteem te vergroten:

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -tvrL +30G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/fsadm --dry-run --verbose check /dev/data/linh
fsadm: "ext4" filesystem found on "/dev/mapper/data-linh".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-linh
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 274424922112 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 74862592
root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -vrL +30G
Executing: /sbin/fsadm --verbose check /dev/data/linh
fsadm: "ext4" filesystem found on "/dev/mapper/data-linh".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-linh
fsck from util-linux 2.33.1
linh: 74099/16752640 files (5.8% non-contiguous), 63802054/66998272 blocks
Archiving volume group "data" metadata (seqno 4).
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Loading table for data-linh (254:3). Suspending data-linh (254:3) with device flush Resuming data-linh (254:3). Creating volume group backup "/etc/lvm/backup/data" (seqno 5). Logical volume data/linh successfully resized. Executing: /sbin/fsadm --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 306637176832 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-linh 74862592
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-linh to 74862592 (4k) blocks.
The filesystem on /dev/mapper/data-linh is now 74862592 (4k) blocks long.
root@linhovo:~# df -h /home/linh

UPDATE: ik was blij verrast dat df de ruimte wist te vinden voor de niet-aangekoppelde partitie. Omdat de beschikbare ruimte overeenkwam met wat ik verwachte, heb ik geen acht geslagen op de details.

Nu ik die bekijk, zie ik dat df wel antwoord op mijn vraag gaf, maar als resultaat de partitie toonde waarin het koppelpunt voor /home/linh zich bevind. De partitie is ondertussen verder gevuld en uitgebreid, het verduidelijkt het verhaal niet meer om de juiste output te tonen.

Les voor de volgende keer: vraag niet de vrije ruimte van het mount point op, maar de vrije ruimte van de partitie: 

root@linhovo:~# df -h /dev/mapper/data-linh
"partition not mounted" (or something of that order)

Print this entry

Geplaatst op

Yunohost onderhoud

Help, de Yunohost is niet bereikbaar!

Troubleshoot

Wat doet het nog? Een webserver bestaat uit een toren van losse systemen. Als een van de systemen het niet doet, stort de rest van de toren in. Vanaf de fundamenten naar boven zijn de bouwstenen die je het makkelijkste kunt controleren:

  1. Staat ‘ie aan?
    • Kun je zelf alleen controleren als hij bij je thuis staat
  2. Geeft het appparaat levenstekenen?
    • Kun je zelf alleen controleren als hij thuis staat
    • Hangt er ook vanaf wat voor appaatje je hebt
    • Orange Pi Zero: met seriele poort, verhaal voor een andere keer
    • Oude laptop: iets typen of muis bewegen
  3. Reageert de server op pings? In het geval van osba.nl:
    • ping 80.127.182.180
    • ping 2001:985:b79a:1:6d21:81ff:a52e:6f3
    • ping -4 osba.nl
    • ping -6 osba.nl
  4. Kun je met SSH in de server komen?
    • ssh admin@domeinnaam.nl
  5. Werkt de admin-pagina nog?
    • ga naar het IP van je server; je kunt het vinden via ping. Bijvoorbeeld:
    • https://[2001:985:b79a:1:6d21:81ff:a52e:6f3]
    • https://80.127.182.180
    • https://osba.nl/yunohost/admin
    • Als het werkt via het IP-adres, krijg je een beveiligingswaarschuwing vanwege het certificaat (SSL of TSL). Als je browser het toestaat, kun je verder gaan met de onveilige instelling. Als je het certificaat bekijkt en je weet dat het bij je server hoort kun je ook inloggen.
  6. Kun je inloggen op de gebruikerspagina?
    • Ga naar het reguliere login-adres voor Yunohost,
    • https://osba.nl/yunohost/sso/

Wat nu?

Het hangt er vanaf hoe ver je gekomen bent. Per nummertje:

  1. Het makkelijkste is natuurlijk als de server gewoon thuis staat en je de stroom kunt controleren. Als het apparaatje aan een batterij hangt, kan het maar zo zijn dat er een paar dagen eerder een stekker uitgetrokken is, en dat je het nu pas merkt.
  2. Kijken of er iets gebeurt gaat eigenlijk hetzelfde als met een laptop, mobiele telefoon of een computer. Vastlopen kan gebeuren als de voeding van de Orange Pi net niet sterk genoeg is. Hij gaat dan wel aan, maar eigenlijk doet ‘ie het voor de helft niet.
  3. Ping kun je voor het hele internet (en alle apparaten thuis) gebruiken om te kijken of ze bereikbaar zijn op het netwerk. Het commando stuurt een berichtje voor het apparaat dat je noemt, en als dat apparaat het ontvangt, stuurt het een antwoord terug. Zo ziet het er bijvoorbeeld uit:

    ping -4 osba.nl
    PING osba.nl (80.127.182.180) 56(84) bytes of data.
    64 bytes from online.osba.nl (80.127.182.180): icmp_seq=1 ttl=64 time=0.457 ms
    64 bytes from online.osba.nl (80.127.182.180): icmp_seq=2 ttl=64 time=0.092 ms

    Je kan een ping sturen naar een IP-adres of naar een domeinnaam. In het geval van IP-adres, kan het een van versie 4 (vier blokjes cijfers met een punt ertussen) of van versie 6 (heel veel cijfers en letters met dubbele punten ertussen) zijn. Daarom de verschillende voorbeelden.
    Voor computers zijn de IP-adressen het makkelijkste. Voor domeinnamen is een extra stap via DNS nodig. Elke extra stap is een stap die kan mislukken.
    Als je server reageert op ‘ping domeinnaam’, dan werkt het ook met minstens een van de twee IP-versies. Andersom hoeft niet. Als het wel werkt met het IP-adres, maar niet met de domeinnaam, dan is er een probleem met DNS. Voor alle Yunohosts die ik zelf ingericht heb, gaat DNS via your-webhost.nl (met een gebruikersnaam met qb….) of via dns.he.net (met de gebruikersnaam die daar bij hoort)
  4. Als er een reactie op de ping terugkomt, kun je proberen om met SSH in te loggen. Dat gaat met:
    ssh admin@domeinnaam
    Je logt in met het wachtwoord dat je ook voor de admin-pagina van Yunohost gebruikt (de witte pagina, met de instellingen).
    1. Misschien is het voldoende om het systeem opnieuw op te starten. Gebruiker ‘admin’ mag dat niet, maar gebruiker ‘root’ mag dat wel. Type:
      sudo reboot
      en dan enter. De verbinding wordt verbroken. Als dat genoeg was, dan is even later je website weer terug.
    2. Als dat niet genoeg was, dan wordt het wat lastiger. Misschien staat er iets in het logboek waarmee je op internet een oorzaak kunt vinden. Type:
      sudo tail -f /var/log/messages
      … en dan enter. De laatste regels van het logboek komen nu tevoorschijn. Als de server nog ergens mee bezig is, dan komt er een regeltje bij.
      Je kan stoppen met kijken door ctrl-c in te drukken.
      Verhaal voor een andere keer.
  5. Soms doet de normale loginpagina het niet, maar de adminpagina het nog wel. Je kan vanuit de adminpagina naar de diagnosepagina gaan. Dat is ook nog wel een beetje lastig, maar makkelijker te lezen dan de berichten rechtstreeks in het logboek. Ik ga er nu niet verder op in.
  6. Als we zover gekomen zijn zonder problemen, dan zou eigenlijk de website gewoon moeten werken. Probeer in te loggen op de zwarte pagina met de gekleurde blokjes. Als je standaaard naar een blog of andere pagina gaat, dan moet je achter het adres ‘/yunohost’ typen, bijvoorbeeld
    https://osba.nl/yunohost
    Je kan dan de verschillende apps proberen, om te zien of ze het allemaal niet doen, of dat er bijvoorbeeld een probleem is met alleen WordPress of alleen met Nextcloud.

Dat was een lang verhaal. Vaak als er een niet te groot probleem is, kun je met deze stappen de oorzaak vinden en verhelpen.

Software bijhouden

Als alles het doet dan is dat fijn. Maar het is wel belangrijk om bij te blijven met beveiligingsupdates. Sommige beveiligingsupdates worden door Yunohost zelf gedaan. Om volledig bij te werken, en ook nieuwe functionaliteit beschikbaar te maken, kun je het systeem bijwerken via de admin-pagina of via SSH.

update via admin-pagina

Een van de menupunten op de admin-pagina is systeem-update. Als je die aanklikt, wordt infomatie over alle updates opgehaald en weergegeven.

Daarna kun je kiezen of je het systeem wil bijwerken of de apps. In het laatste geval kun je ze ook een-voor-een bijwerken. Soms is dat nodig omdat de bovenste een probleem heeft bij de update, en de rest niet in een rijtje afgewerkt wordt. Soms wil je juist weer snel alleen het onderste programma bijwerken.

Bovenin de pagina wordt weergegeven bij welke stap van de upgrade Yunohost is: downloaden van de nieuwe versie, backup maken, installeren, etc. Daar wordt ook een berichtje gegeven als de upgrade klaar is, of als er juist iets fout gaat.

Update via SSH

Inloggen met SSH kan met een SSH-programma op je computer of op je telefoon, of via “Terminalscherm in je browser / shell in a box”. Je logt in met admin en het wachtwoord van admin (er komen bij het wachtwoord geen sterretjes of balletjes in beeld, dus gewoon typen en enter drukken).

Daarna kun je met drie commando’s het systeem bijwerken, telkens met enter achteraan de regel:

sudo yunohost tools update
sudo yunohost tools upgrade --system
sudo yunohost tools upgrade --apps

Laatst werkte Nextcloud niet meer na een upgrade. Bij het openen van Nextcloud werd een melding over onderhoudsmodus / maintenance mode getoond.

Het bleek dat Nextcloud na de update een nieuwe versie van een programmeertaal nodig had (PHP 7.3 ipv PHP 7.0). De upgrade dat wel de nieuwe versie van PHP geinstalleerd, maar gebruikte standaard nog versie 7.0. Daardoor lukte het me niet om de onderhoudsmodus te deactiveren:

sudo -u nextcloud php /var/www/nextcloud/occ maintenance:mode --off

gaf een foutmelding. Ik heb PHP handmatig laten wijzen naar versie 7.3 met sudo update-alternatives –set php /usr/bin/php7.3 , maar achteraf gezien had ik misschien moeten proberen de aanroep van PHP aan te passen ( dus sudo -u nextcloud /usr/bin/php7.3 /var/www/nextcloud/occ maintenance:mode –off ), dat merk ik vast later weer. Nextcloud doet het in ieder geval weer, en de rest van het systeem ook.

Print this entry

Geplaatst op

Draadloze vloerverwarmingsthermostaat

We hebben infrarood-vloerverwarming geïnstalleerd. De verwarming is, bij gebrek aan themostaat, nog niet aangesloten. Vanaf het begin was mijn idee om een Arduino of vergelijkbaar te gebruiken om zelf een thermostaat te bouwen. Het was niet alleen goedkoper en flexibeler, maar ook een uitstekende reden om met Arduino aan de slag te gaan.

De onderdelen zijn ondertussen aangekomen:

  • ESP32, het brein van elke thermostaat
  • Relais, voor het daadwerkelijke aan/uitschakelen van de verwarmingsfilm
  • 10k NTC’s liggen al onder de vloer, samen met de film zelf

De afzonderlijke functies die ik nodig heb/wil integreren zijn makkelijk online te vinden, en het samenvoegen ervan ging aanvankelijk best vlot. Het resultaat was bijna wat ik nodig had, enkel de sensor voor omgevingstemperatuur en het instellen van een variabele doeltemperatuur ontbraken. En alles werkte in de verkeerde volgorde. Welke functies allemaal, en wat ging er mis in de eerste iteratie?

  • Temperatuur meten
  • Thermostaat instellen
    • Aan de ene kant de omgevingstemperatuur: de gewenste temperatuur in de kamer
    • Aan de andere kant de vloertemperatuur: de vloer mag niet warmer dan 29 graden Celsius worden
  • Relays aan- of uitschakelen afhankelijk van de gemeten temperatuur en de instelling van de thermostaat
  • Toegankelijk via WiFi op het interne domotica-netwerk

Zoals gezegd, van iedere afzonderlijke functie zijn er voorbeelden voor Arduino en, in mindere mate, voor ESP32 te vinden. Ik had uiteindelijk een programma dat:

  • Verbinding zoekt via WiFi
  • Een web-interface toont om het relais aan of uit te schakelen
  • De temperatuur meet als je een button op de webinterface indrukt
  • Het relais schakelt gebaseerd op de gemeten temperatuur

De thermostaad deed dus niets met het relais totdat je er zelf wat mee deed. Niet zo nuttig. Het moet juist andersom werken:

  • Bekijk de huidige staat van het relais
    • Staat ‘ie uit? Dan de omgevingstemperatuur vergelijken met de ingestelde thermostaatwaarde
    • Staat ‘ie aan? Dan de vloertemperatuur vergelijken met de ingestelde maximumwaarde
  • Afhankelijk van de uitkomst hierboven, het relais schakelen of in de huidige staat laten
  • Verbind gedurende een minuut met WiFi
  • Toon in die tijd de web-interface
  • Geef de mogelijkheid de thermostaat in te stellen
  • Begin van boven af aan

De volgende stap is om een domoticaserver een interface voor de thermostaat te laten serveren, en dat de ESP32 de domoticaserver zo nu en dan vraagt wat de gewenste temperatuur is. Op die manier toont de ESP32 niet zo lang een web-interface via WiFi, met zodoende minder energieverbruik en hogere veiligheidsgraad. Maar dat komt later

Print this entry