Alle Beiträge von adlerweb

dd-Backupfortschritt mit pv visualisieren

Vollsicherungen gesamter Festplatten oder Partitionen lassen sich mit dem Unix-Tool „dd“ schnell und einfach anfertigen. Während das Tool automatisiert wohl keine Wünsche offen lässt ist es ein wahrer Quählgeist, wenn man dringend auf die Fertigstellung eines Jobs wartet, denn eine automatische Ausgabe des Fortschirttes ist nicht vorgesehen. Zwar kann man sich hier behelfen, in dem man über den „kill„-Befehl das Signal „SIGUSR1“ an den Prozess sendet und so die Anzeige der verarbeiteten Datenmenge erzwingt, wirklich komfortabel ist dies jedoch nicht.

Senden von SIGUSR1

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/11/pv1-300×98.png
Um das Signal SIGUSR1 an einen Prozess zu senden sollte im ersten Schritt dessen Prozess-ID (PID) ermittelt werden, hierzu kann man in der Ausgabe „ps“ nach dem zuvor gestarteten „dd„-Befehl suchen. Ich nutze zur Suche im Beispiel „grep„. Da zum Zeitpunkt des Schreenshots mehrere „dd„-Prozesse liefen suche ich zudem nach der Quelle des Testjobs (urandom).

kronos ~ # ps xa | grep "dd" | grep urandom
23204 pts/24   R+     0:24 dd if=/dev/urandom of=/dev/zero

Mit dieser ID kann man nun das Signal über den Befehl „kill“ absetzen. „dd“ verarbeitetet dieses Signal intern, das Programm wird hierdurch nicht beendet.

kronos ~ # kill -SIGUSR1 23204

Während auf der aktuellen Konsole keine Ausgabe erfolgt müsste dd nun einen Status ausgeben, welcher u.A. die verarbeitete Datenmenge sowie die Geschwindigkeit enthält:

162183+0 Datensätze ein
162182+0 Datensätze aus
83037184 Bytes (83 MB) kopiert, 37,7423 s, 2,2 MB/s

 

Wer sich einen übersichtlicheren und automatisierten Status wünscht kann hier mit dem Zusatztool „pv“ (Pipe Viewer) nachhelfen. Statt die Daten direkt von „dd“ an das Ziel schreiben zu lassen werden sie durch „pv“ geleitet, welches wiederum eine statistische Auswertung anzeigt. Als Ziel kann dann über einen weiteren „dd„-Prozess wieder eine Datei oder Gerät verwendet werden, alternativ gehen natürlich auch Kompressionstools wie „gzip“ oder man lässt die Daten z.B. mittels „nc“ (netcat) oder „SSH“ (Secure Shell) zur Speicherung an einen anderem Rechner senden.

Beispiele mit „pv

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/11/pv2.png

Daten in Datei speichern

dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | dd of=vm-102-disk-1.img
  15GiB 0:20:34 [  19MiB/s] [12,5MiB/s] [============================================>                                                      ] 46% ETA 0:23:12

Daten über gzip komprimieren und in Datei speichern

dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | gzip > vm-102-disk-1.img.gz
  15GiB 0:20:34 [  19MiB/s] [12,5MiB/s] [============================================>                                                      ] 46% ETA 0:23:12

Daten über gzip komprimieren, per SSH mit schwacher Verschlüsselung an einen anderen Rechner senden und dort in Datei speichern

dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | gzip | ssh -c arcfour,blowfish-cbc backup@cautio.lan.adlerweb.info 'dd of=/var/backup/vm-102-disk-1.img.gz'
Password:
 251MiB 0:00:23 [12,6MiB/s] [10,8MiB/s] [>                                                                                                  ]  0% ETA 0:49:38

 

Wichtig hierbei ist, dass „pv“ am Ende die Größe der Quelldatei/des Quellgerätes genannt wird, in diesem Fall 32 GB. Ingesamt bedeuten die Optionen folgendes:

-p Fortschrittsbalken anzeigen
-t Bisher vergangene Zeit anzeigen
-e ETA, also erwartete Restzeit, anzeigen
-r Aktuelle Datenrate, also „Geschwindigkeit“, anzeigen
-a Durchschnittliche Datenrate anzeigen
-b Bereits kopierte Datenmenge anzeigen
-s Größe der Quelle in Byte, k,m,g,… möglich

Alternative Reihenfolge zum besseren Merken: pertabs (per tabs) oder für Nutzer diverser Imageboards betraps.

Die Ausgabe ist wie folgt zu lesen:

  15GiB        0:20:34  [  19MiB/s] [12,5MiB/s] [======      ] 46% ETA 0:23:12
Kop.Datenmenge|Verg.Zeit|Datenrate|Ø Datenrate | Fortschritt      |Restzeit

Damit wäre der nervöse Admin mit beruhigenden Statistiken versorgt und weiß wie lange er sich noch gedulden muss – eine Ausrede weniger die Backups zu vernachlässigen. Natürlich kann „pv“ auch für andere Konstrukte verwendet werden, welche mit einer Pipe arbeiten.

MySQL/MariaDB unter Linux mit ZFS: Operating system error number 22 in a file operation

Nachdem LVM eine Qual ist wenn es um die Konfiguration von RAID geht (anm: Natives LVM-Raid, nicht md) und btrfs auf mehreren meiner Systeme gerne mal Dateien vergisst habt ich mich nach langer Zeit nochmal an ZFS gewagt. Die Funktionspalette ist beeindruckend: Integriertes RAID, integriertes Volumemanagement, Subvolumes, Kompression, Quota, etc. Alles natürlich verzahnt, sodass ein RAID-Rebuild wirklich nur belegte Dateisystembereiche rekonstruiert. Einzig die statische RAID-Konfiguration ist wenn man von LVM kommt etwas bedauerlich. Ansonsten scheint die Linux-Portierung des eigentlich von Solaris stammenden Systems inzwischen durchaus stabil.

Genug geredet, eigentliches Thema: MySQL unter ZFS. Als guter Einstieg sollte man hier einen Blick auf die Arch-Wiki werfen, welche einen Blick auf die Blockgrößen und Cache-Eigenheiten wirft. Doch egal wie: MySQL bzw. MariaDB haben noch eine Gemeinheit im Paket: Direct IO.

Da MySQL ein eigenes Caching implementiert versucht es über O_DIRECT die Dateicaches des Betriebssystems zu umgehen. Im Falle von ZFS ist dies durch den Aufbau nicht sonderlich hilfreich und wird durch den Linux-Treiber nicht unterstützt. Während die meisten Programme automatisch auf klassisches IO zurückfallen verabschiedet sich MySQL mit folgenden Log-Einträgen:

141019 18:07:42 InnoDB: Operating system error number 22 in a file operation.
InnoDB: Error number 22 means ‚Invalid argument‘.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File name ./ib_logfile0
InnoDB: File operation call: ‚aio write‘.
InnoDB: Cannot continue operation.

Um das Problem zu beheben kann man die Datenbank über /etc/mysql/my.cnf in den klassischen IO-Modus zwingen, hierzu unter [mysqld] folgenden Eintrag ändern bzw. hinzufügen:

innodb_use_native_aio=0

im Anschluss sollte die Datenbank wieder wie gewohnt starten. Hinweis: Fehlender Direct-IO bringt auch Probleme mit KVM/LibVirt, auch hier sind ggf. Anpassungen notwendig.

[Gentoo] Installation von dev-ruby/ffi-1.9.4 schlägt fehl

Die Installation von dev-ruby/ffi-1.9.4, welches als Dep gezogen wurde, machte auf einem Server Probleme. Unter anderem war folgende Meldung zu lesen:

cannot load such file -- rspec/core/rake_task

Woher die Anforderung kam oder warum keine Dep da ist konnte ich nicht direkt sehen, ein manuelles Installieren von dev-ruby/rspec sollte jedoch die nötigen Voraussetzungen schaffen um das Kompilieren zu ermöglichen.

[Gentoo] Update sys-apps/man-db schlägt fehl

Auf mehreren Servern quittierte das Update von sys-apps/man-db-2.6.6 mit folgender Meldung:

BEGIN failed--compilation aborted at /usr/bin/po4a line 547.

Schuld ist Perl, entsprechend kann das gute, alte perl-cleaner --all Wunder wirken.

[Gentoo] Slot-Conflice durch Perl-Updates

Schon etwas älter, aber ab und zu stoße ich trotzdem drauf: Durch Perl kommt es bei Updates zu einem Slot-Conflice / Blocked Packages. Die Lösung wird z.T. gleich mitgeliefert:


* Remove all perl-core packages from your world file
* emerge --deselect --ask $(qlist -IC 'perl-core/*')
* Update all the installed Perl virtuals
* emerge -uD1a $(qlist -IC 'virtual/perl-*')
* Afterwards re-run perl-cleaner
perl-cleaner --reallyall

Fotos Kirmes Saffig 2014 / Pfarreienfest 2014

Die Fotos der Kirmes Saffig 2014 sind nun online, etwas verspätet finden sich zudem Impressionen des Pfarreienfestes in der Gallery.

Arch Linux: Grafik-Software streikt nach Mesa-Update (10.2.7-2)

Seit vermutlich dem letzten Mesa-Update auf 10.2.7-2 vom letzten Wochenende ist offenbar OpenGL nicht mehr voll funktionsfähig – in meinem Fall verabschiedete sich Hugin mit der folgenden Meldung:

/usr/share/hugin/data/plugins/crop_cp.py
   CAT:Control Points
   NAM:Crop Control Points
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
/usr/share/hugin/data/plugins/top_five.py
   CAT:Control Points
   NAM:keep 5 CPs per image pair
/usr/share/hugin/data/plugins/shooting_pattern.py
   CAT:initial distribution
   NAM:6-1-1 Shooting Pattern
LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb
Speicherzugriffsfehler (Speicherabzug geschrieben)

Der Fehler ist schon im Arch-Bugtracker zu finden. Eine aktualisierte Mesa-Version (10.2.7-3) findet sich in Testing, hiermit tritt der Fehler nicht mehr auf.

Edit: Laut Website soll 10.2.7-3 wohl seit gestern in extra sein, auf meinem Mirror war dies jedoch noch nicht der Fall.

PEBCAK: Negative Temperaturen gibt’s ja auch…

In der BitNotice #44 hatte ich „mal schnell“ ein Script gebaut um die Werte eines DS18B20 Temperatursensors über einen Raspberry Pi in Volkszähler zu schaufeln. Was irgendwie nicht so ganz aufgefallen ist: Das Script konnte nur Plusgrade. Jetzt steht auf Github eine überarbeitete Version mit „-“ und etwas mehr Fehlerbehandlung. Danke an Peter, dessen Kühltruhe den Fehler aufgedeckt hat.