Archiv der Kategorie: Software

Alles was mit Software zu tun hat

ext4 vs. BTRFS – mal wieder

OK, ok, zugegeben, das Thema gibt’s zu Hauf im Netz, aber ich vertraue lieber eigenen Zahlen: Was ist schneller: ext4 oder btrfs? Hintergrund ist ein Backupzwischensystem, welches große Datenmengen schnell verarbeiten muss. Die Kompression von BTRFS wäre angesichts der Kosteneinsparung durch weniger Plattenverbrauch ein schöner Bonus, aber darf nicht auf Kosten der Geschwindigkeit gehen.

Das System ist ein „Low-End“ Dualcore (Intel(R) Pentium(R) CPU G645 @ 2.90GHz) mit 16GB RAM und 4 Hitachi Deskstar 5K3000 á 2TB. Die Platten mit 5300rpm sehen zwar auf den ersten Blick etwas schwachbrüstig aus, da die Daten aber vermutlich sehr groß und entsprechend hoffentlich am Stück geschrieben werden sollte die geringe Drehzahl hoffentlich nicht wirklich ins Gewicht fallen. Das Mainboard (ASRock H77 Pro4/MVP) verfügt über zwei SATA-Controller – der Intel® H77 steuert neben 4 SATA2-Ports zusätzlich 2 Ports mit SATA3 bei, ein ASMedia ASM1061 stellt 2 zusächliche SATA3-Ports bereit. Die Platten wurden über die SATA3-Ports an beide Controller verteilt.

Die Tests liefen auf einem Arch Linux x86_64-System mit Kernel 3.11.2, als RAID kam das im Kernel enthaltene md-Framework zum Einsatz, auf die bei BTRFS integrierte RAID-Funktion verzichte ich, da ich separate Schichten für besser wartbar halte.

Erst einmal die rohen Werte der Platte: Diese lieferten im Test jeweils etwa 140MB/s sequential Read.

Erster Versuch: 1GB sequential Write, die Platten werden dabei erst mal als RAID5 genutzt, in der Hoffnung, dass die Geschwindigkeit noch ausreichend ist. Das Ergebnis ist etwas ernüchternd:

1GB Sequencial File Write
RAID5, EXT4 99MB/s
RAID5, BTRFS 134MB/s
RAID5, BTRFS (LZO) 144MB/s

BTRFS liegt zwar klar vor ext4 und auch die Kompression bringt auf Grund der gut komprimierbaren Quelle einen Geschwindigkeitsschub, insgesamt liegt die Leistung aber unter meinen Anforderungen – 144MB/s könnte die 2GBit/s Uplink grade so bewältigen, aber eigentlich hätte ich schon gerne noch etwas Reserve… Die Antwort dürfte klar sein: Da die Daten hier nur zwischengelagert werden bin ich auf das RAID5 nicht angewiesen, also RAID0 ftw – der erste Blick aufs rohe Device ist vielversprechend: 490MB/s sind ein guter Start – und was machen die Dateisysteme daraus?

RAID0, EXT4 349MB/s
RAID5, BTRFS 376MB/s
RAID5, BTRFS (LZO) 382MB/s

Viel ändert sich nicht – BTRFS mit Kompression erreicht gegenüber ext4 knapp 10% höhere Schreibraten. Die 380MB/s dürften erst bei etwa 4GBit/s uplink an ihre Grenzen stoßen – bis die fällig sind dürfte eher der Plattenplatz ausgehen. Sieger gefunden würde ich sagen: BTRFS schlägt ext4 sowohl bei Geschwindigkeit als auch beim Funktionsumfang – ob es auch die Stabilität der ext-Systeme nacheifern kann wird die Zeit zeigen.

Hinweis zum Gentoo-Update auf www-apps/owncloud-5.0.12

Kurzer Hinweis zu letzten Owncloud-Update unter Gentoo: Durch eine nicht ganz performante Funktion scheint das ebuild in der Install-Phase zu hängen. Auf einem Atom-System dauerte es 2 Stunden bis Portage den Vorgang abschließen konnte, auf einem i7 mit RAID 15 Minuten, also nicht ungeduldig werden und nach Anstoßen des Updates doch erst mal eine (Familien)Pizza essen gehen. Der Installationsvorgang kann mit lsof auf den Temp-Ordner (/var/tmp/portage/) beobachtet werden.

ownCloud-Update hängt in Schleife

Wenn das letzte ownCloud-Update immer nur „Updating ownCloud to version 5.0.11, this may take a while.“ anzeigt und die Meldung ohne Fehler ständig neu lädt hilft es den Nutzer des Webservers wieder Schreibrechte auf die nötigen Verzeichnisse zu geben…

Linux LVM: „Hängende“ Snapshots entfernen

Was ein Murks: Einer meiner Server brauchte dank Problem des Festplattentreibers einen Neustart. Nach dem Boot fiel mir auf, dass im LVM-System einige alte Snapshots von Systemtests liegen geblieben sind. Schnell mal aufräumen – oder auch nicht, denn dummerweise wollte LVM da nicht mitspielen. Erst mal eine kleine Übersicht des Systems:

root@rescue:~# pvs
PV VG Fmt Attr PSize PFree
/dev/md2 storage lvm2 a-- 2.70t 1.57t
root@rescue:~# vgs
VG #PV #LV #SN Attr VSize VFree
storage 1 32 9 wz--n- 2.70t 1.57t
root@rescue:~# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
[...]
test-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test-www4-data storage swi-a-s- 70.00g www4-data 38.39
test-www4-root storage swi-a-s- 20.00g www4-root 63.09
test2-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test2-www4-data storage swi-a-s- 70.00g www4-data 37.31
test2-www4-root storage swi-a-s- 20.00g www4-root 59.58
www4-boot storage owi-a-s- 512.00m
www4-data storage owi-a-s- 73.24g
www4-root storage owi-a-s- 20.00g
[...]

Man sieht die mit „test“ beginnenden Snapshots welche entfernt werden sollen. Üblicherweise reicht hier ein lvremove welches folgende Ausgabe brachte:

Do you really want to remove active logical volume test-www4-root? [y/n]: y
/sbin/dmeventd: stat failed: No such file or directory
/sbin/dmeventd: stat failed: No such file or directory
Unable to deactivate open storage-test--www4--root-cow (253:2)
Failed to resume test-www4-root.
libdevmapper exiting with 3 device(s) still suspended.

Ab diesem Punkt ist die LVM-Verwaltung faktisch tot. Kommandos wie z.B. lvs hängen sich auf und geben keine Ausgabe. Erst nach einem Reboot ist die Verwaltung wieder möglich, dann taucht der soeben gelöschte test-www4-root wieder auf, ist allerdings kein Snapshot mehr und lässt sich nun auch fehlerfrei entfernen. Keine schöne Lösung, denn ich habe viele Snapshots und dazu eine Abneigung gegen Reboots. Mit strace findet man im hängenden Zustand folgendes:

ioctl(3, DM_TABLE_STATUS, 0x81b5a40) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, BLKGETSIZE64, 0xffcc33a8) = 0
close(5) = 0
close(4) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, BLKGETSIZE64, 0xffcc3378) = 0
close(4) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
ioctl(4, BLKBSZGET, 0x8174458) = 0
_llseek(4, 21474770944, [21474770944], SEEK_SET) = 0
read(4,

Der Auslöser scheint also die Snapshotquelle zu sein, nicht der Snapshot selbst. Eine Suche brachte mich zur Debian-ML auf der das Problem beschieben wird – dankenswerterweise funktionierte der Workarround auch in meiner Situation:

– Der lvremove-Befehl wird in einer Shell abgesetzt und hängt sich auf
– Auf einer zweiten Shell setzt man die Snapshotquelle manuell mit folgenden Befehl wieder in Gang: „dmsetup resume /dev/storage/www4.root“
– Die erste Shell reagiert wieder, der Snapshot sollte verschwunden sein
– Ggf. zurückgebliebene Laufwerksleichen werden mit „dmsetup remove /dev/storage/xxx“ entfernt

Gentoo: net-misc/bridge-utils lässt sich nicht installieren

Dafuq? Während einer Gentoo-Installation ließ sich plötzlich eine 802.1d Ethernet-Bridge nicht mehr korrekt ansprechen. Ein „brctl“ zeigt lediglich „Command not found“. Kann doch nicht sein – net-misc/bridge-utils habe ich eben noch emerged und es gab keine Fehler. Ein „equery files bridge-utils“ zeigt ebenfalls seltsames:

equery files bridge-utils
* Searching for bridge-utils ...
* Contents of net-misc/bridge-utils-1.4:
/usr
/usr/share
/usr/share/doc
/usr/share/doc/bridge-utils-1.4
/usr/share/doc/bridge-utils-1.4/AUTHORS.bz2
/usr/share/doc/bridge-utils-1.4/ChangeLog.bz2
/usr/share/doc/bridge-utils-1.4/FAQ.bz2
/usr/share/doc/bridge-utils-1.4/FIREWALL.bz2
/usr/share/doc/bridge-utils-1.4/HOWTO.bz2
/usr/share/doc/bridge-utils-1.4/PROJECTS.bz2
/usr/share/doc/bridge-utils-1.4/README.bz2
/usr/share/doc/bridge-utils-1.4/RPM-GPG-KEY.bz2
/usr/share/doc/bridge-utils-1.4/SMPNOTES.bz2
/usr/share/doc/bridge-utils-1.4/THANKS.bz2
/usr/share/doc/bridge-utils-1.4/TODO.bz2
/usr/share/doc/bridge-utils-1.4/WISHLIST.bz2
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/brctl.8.bz2

Die Binary fehlt?!

Ein neues emerge unter Aufsicht zeigt auch warum:

[...]
error: field 'ip6' has incomplete type
make[1]: *** [libbridge_if.o] Error 1
make[1]: *** [libbridge_init.o] Error 1
make[1]: *** [libbridge_devif.o] Error 1
[...]

Das kompilieren bricht wegen modifizierter Header-Dateien bei Kerneln => 3.8 ab, das ebuild registriert dies jedoch nicht und meldet eine erfolgreiche Installation. Die Lösung sollte inzwischen bereits verfügbar sein: Mit der seit einigen Tagen stabilen Version net-misc/bridge-utils-1.5 sollte das Problem behoben sein.

Arch Linux: Mehrere X-Server, Systemd und VT-Switch

Die Migration auf Systemd hat noch immer ihre Nebenwirkungen auf meinem System: Ich verwende hauptsächlich ein Multimonitor-Setup auf meinem Rechner. Leider unterstützen nicht alle Anwendungen ein solches Konstrukt fehlerfrei, daher nutze ich von Zeit zu Zeit einen zweiten XOrg mit nur einem Monitor um die Software zu betreiben. Um diesen zu starten nutzte ich bisher den Befehl startx -- :1 -layout LayoutSingle. Über das übliche VT-Switch konnte ich ggf. zwischen den Serven wechseln, die Multimonitor-Lösung befand sich auf vt7 (Ctrl-Alt-F7) und der zweite Server mit nur einem Monitor auf vt8 (Ctrl-Alt-F8).

Nach der Migration auf Systemd war damit Schluss: Zwar startete der zweite X-Server normal und ich konnte ihn benutzen, habe ich ihn aber einmal auf eine andere Konsole verlassen gab es keine Möglichkeit mehr auf den Bildschirm zurück zu kommen. Zum Glück ist die Lösung recht einfach und offensichtlich (wenn man sie erst mal gefunden hat) – der Befehl zum Starten heißt nun startx -- :1 -layout LayoutSingle vt8

et-sdl-sound: Segfault – Patch

Der ET-spielenden Linux-Bevölkerung ist „et-sdl-sound“ sicher ein Begriff: Dieser „Hack“ erlaubt es über LD_PRELOAD das Spiel vom bisherigen „Open Sound System“ (OSS) loszulösen und per SDL auch z.B. mit ALSA oder Pulse zu betreiben und somit die Sondausgabe auf aktuellen Distributionen zu ermöglichen. Leider haben die letzten Updates meines Arch Linux Systems gleich mehrere Fehler ausgelöst: Im ersten Schritt änderte sich (durch die /usr/bin-Migration?) die CRC der ET-Binary. Da über diese Prüfsumme der Hack das Spiel erkennt war keine Tonausgabe mehr möglich. Ein weiteres Problem stellt inzwischen wohl die Nutzung von stdout dar – warum auch immer, bei jeder Ausgabe verabschiedet sich das Spiel per Segfault.

Für beide Probleme habe ich nun eine aktualisierte Version in meinem Github-Repo – die CRC der Arch-Linux Version wurde ergänzt, der Code grob für neuere Compiler umgestellt und die Info-Ausgaben in die Datei /tmp/et-sdl-sound.log umgeleitet.

[Kurztipp] Standby nach mehreren Aufgaben

Derzeit bin ich auf meinem Rechner einige Videos am recodieren – über Nacht stört es nicht, aber praktisch wäre es schon den PC nach getaener Arbeit abzuschalten. Ein einfaches anhängen des Kommandos funktioniert nicht, da ich mehrere Prozesse simultan am laufen habe. Da alle CPU-intensiv sind sieht die qnd-Lösung jetzt folgendermaßen aus: Alle 5 Sekunden wird die Systemload geprüft, ist sie unter 1 schaltet das System ab. Einfach, aber sollte seinen Zweck erfüllen.

while : ;do echo -n '.' ; if [ `cat /proc/loadavg | cut -d '.' -f 1` -lt 1 ] ;then pm-hibernate ; break ;fi ; sleep 5 ;done

Videostabilisierung unter Linux

Egal wie ruhig man ist: Auf großen Zoomstufen oder beim Bewegen verwackelt fast jedes Video. Professionelle Aufnahmegeräte bieten für diesen Zweck meist eine Stabilisierung in Kamera oder Objektiv, dies ist jedoch aufwändig und kostet entsprechend viel Geld. Besitzer von Consumergeräten müssen aber nicht ganz auf eine solche Stabilisierung verzichten: Viele Videoeditoren bieten entsprechende Bildfilter, welche (auf Kosten der Videoqualität) softwareseitig die Stabilisierung übernehmen. Als kostenlose Lösung ist vielen die entsprechende Funktion der Videoplatform YouTube bekannt, jedoch lässt sich diese nur auf komplette Videos anwenden und ist nicht konfigurierbar, zudem möchte man nicht jedes Video auf der zu Google gehörenden Platform bereitstellen. Leider sieht es unter Linux dünn aus – zwar kann man über wine die Lösung Virtualdub/Deshaker nutzen und der Editor KDEnlive bietet passende Filter im Menü, beide Lösungen lassen sich jedoch nur schwer automatisieren und leidet unter nervigen kleinen Bugs.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2013/05/kdenlivestab.png

Um nun bei mir das ganze zu erschlagen habe ich ein Script geschrieben, welches alles nötige übernimmt. Die eigentliche Stabilisierung steckt in der Software transcode, da diese jedoch mit vielen Codecs Probleme hat muss das Video entsprechend vorbereitet werden. Durch den Zwischenschritt als MPEG2 ist temporär ein vielfaches des ursprünglichen Speicherplatzes nötig, der sollte beim Umgang mit Videos ja ohnehin reichlich vorhanden sein. Das Ausgabeformat ist derzeit auf 8MBit/s x264 mit 128k MP3 eingestellt, der Stabilisierungsfilter läuft mit Standardwerten.

ffmpeg -i $1 -vcodec mpeg2video -b:v 10000k $1.mpg
ffmpeg -i $1 -acodec libmp3lame -b:a 128k $1.mp3
transcode -J stabilize -i $1.mpg -y null,null -o dummy
transcode -J transform -i $1.mpg -y xvid,pcm -w 10000k -o $1.stab.temp.mp4
ffmpeg -i $1.stab.temp.mp4 -i $1.mp3 -vcodec libx264 -acodec copy -b:v 8000k -map 0:0 -map 1:0 $1.stab.avi
rm $1.stab.temp.mp* $1.mp3 $1.mpg $1.*.trf

Voraussetzungen sind ffmpeg und transcode. Debian/Ubuntu liefern zum Teil statt ffmpeg dessen Fork avconf, in diesem Fall einfach im Script den Befehl anpassen.

http://www.youtube.com/watch?v=HMkRF2yz8M0

Zurück unter den Lebenden: @Saffig mit News & Terminen

Nach der Umgestaltung der Internetseite der Ortsgemeinde Saffig bin ich nun auch dazu gekommen den Twitter-Bot auf das neue System umzustellen, damit gibt es jetzt wieder aktuelle Nachrichten aus dem Rathaus und Hinweise auf Veranstaltungen direkt in die Timeline.