Schlagwort-Archive: Linux

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

Linux: Anzahl der geöffneten Dateien pro Prozess anzeigen

*Poff* – das war die Wand der maximal geöffneten Prozesse auf einem Linux-System – praktisch wäre es jetzt noch zu wissen welcher Prozess dafür verantwortlich ist. In diesem Fall hilft folgender Befehl – er erstellt eine Liste aller Prozesse mit der Anzahl der geöffneten Dateien, die verschwenderichsten oben:

lsof | cut -d ' ' -f 1 | uniq -c | sort -r

Auf der Suche nach den inodes

So ein Linux-Server mit ext4 ist nicht so schnell klein zu bekommen – ich schaffs aber natürlich trotzdem. Auf einem meiner App-Server verabschiedete sich übers Wochenende der Datenbankserver. Diagnose eindeutig: Platte voll, 0 Bype frei. Der Auslöser ist auch schnell ausgemacht – mangels logrotate haben sich über 8GB in /var/log angesammelt. Klare Sache – Logs löschen, Dienste neustarten undnichts. Platte voll. Dafuq? Am Platz liegts nicht – dort sind die 8GB nun frei – ich vermute Böses…

# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/root 23G 14G 8.2G 62% /
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 1474560 1474560 0 100% /

Treffer versenkt – die Inodes sind voll. Aber warum? Nach kurzem Gegoogle gehe ich davon aus, dass meist eine Datei = ein Inode ist, also wird die Bash-Keule ausgepackt:

(for i in `find / -xdev -type d 2>/dev/null` ;do (echo -n `ls -1a "$i" | grep -vP "^(.|..)$" |wc -l` && echo " - $i") ;done) | sort -n

Dieser Code erzeugt eine Liste aller Ordner auf dem Device der Root-Partition – aufsteigend nach der Anzahl der Dateien sortiert. In meinem Fall ist der Schuldige relativ eindeutig:

[...]
1460 - /usr/share/man/man1
1620 - /usr/portage/metadata/cache/dev-perl
1620 - /usr/portage/metadata/md5-cache/dev-perl
1692 - /usr/portage/metadata/glsa
4554 - /usr/share/man/man3
972513 - /var/nagios/home/.maildir/new

Ich sollte mal ein paar Mails löschen -Oder auch nicht, denn…

rm *
-bash: /bin/rm: Argument list too long

also muss auch hier getrickst werden:
find ./ -exec rm {} +

NVidia X.Org Video-RAM information leak

Bereits seit etwa einem Jahr ist mir beim Start von X.Org – oder eher gesagt beim laden von Gnome – ein seltsames Flackern auf mehreren Rechnern aufgefallen. Meist trat es nach abstürzen oder Neustarts auf, nicht jedoch wenn der PC vollständig abgeschaltet war. Da mir einige der Muster im Flackern bekannt vor kamen griff ich Heute mal zur Digitalkamera und zeichnete es auf. Das Ergebnis: Es ist tatsächlich kein wildes Flackern, sondern Bildausschnitte diverser vor dem Neustart verwendeten Programme! Hierbei ist es nicht das letzte Bild, sondern z.B. auch Programme, welche im Hintergrund aktiv waren (also z.B. auch Ausschnitte des Browsers wenn der Bildschirmschoner zuletzt aktiv war). Im heutigen Fall hatte ich den Rechner sogar kurz (~500mA) vom Strom genommen (Stecker gezogen), da sich der Kernel aufgehangen hatte und der PC keinen Reset-Knopf besitzt – dennoch konnte man Bildausschnitte erkennen. Bisher ist mir das Phänomen auf meinem Privat-PC (ArchLinux, GeForce 8600GT, X.org 1.12.2-1, nvidia 295.53-1, Xinerama Multihead) und meinem Arbeits-PC (GeForce 9600GT, X.Org 1.11.2-r2, NVidia 295.20-r1, NVidia TwinView) begegnet. Könnte mir durchaus vorstellen, dass ein Angreifer über diese Methode die „Sicherheit“ des Bildschirmschoners umgehen und so an Informationen über die verwendeten Programme gelangen könnte. Da hierzu offenbar nur ein gewisser Zustand der Grafikkarte erreicht werden muss könnte dies auch per OS auf einem Stick erfolgen und so die Informationen trotz Festplattenverschlüsselung preis geben. Im Gegensatz zu den bekannten Cold-Boot-Attacks muss hierzu nichts an der Hardware geschraubt werden.

—EN—
About a year ago i noticed a strange flickering while loading X.Org/GNOME on several of my PCs. It appeared mostly after crashed and restarts, not if the PC was turned off for some time. Since i noticed several patterns inside this flicker i grabed my camera today and recorded the process. The result: its not a random flicker but image-parts of programs that ran before the reboot! They where not limited to the last shown picture before the boot – also programs that where running but not shown (like a browser when a screensaver was active) appeared. In today’s case i even cut the power (~500ms via power cord, Kernel crashed and the pc has no reset-button) – still i was able to recover image-parts. I could observe the behaviour an my home-PC (ArchLinux, GeForce 8600GT, X.org 1.12.2-1, nvidia 295.53-1, Xinerama Multihead) and my PC at work (GeForce 9600GT, X.Org 1.11.2-r2, NVidia 295.20-r1, NVidia TwinView). I could imagine that attackers could use this to bypass a screensaver and get information about running programs. Since you only need to reach a certain state of the GPU it should be possible to use an USB-based OS and grep this info even if the local harddisk is encrypted. Contrary to known Cold-Boot-Attacks there is no need to open the case.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2012/06/capture-clean-300×226.jpgBild: https://www.adlerweb.info/blog/wp-content/uploads/2012/06/capture-cap-300×226.jpg

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

Back to the Roots: Gnome 2 – Fork „MATE“ auf Archlinux

Ja, Gnome3 ist toll – wenn man auf grafischen Schnickschnack steht. Zugegeben, auf Netbook und co nutze ich Gnome3 gerne, aber auf meinem PC zählen die Grafikeffekte nicht – im Gegenteil: Sie stören beim Arbeiten. Fehlende Panels, mangelnde Leistung und Probleme mit mehreren Monitoren haben mich seit dem Update nach über 10 Gnome-Jahren dazu gezwungen auf Fluxbox zu wechseln. Das läuft zwar schnell, aber die schonen Panels fehlen mir noch immer – doch jetzt naht Rettung! Mit dem Projekt „MATE“ gibt es einen Gnome2-Fork, welcher einen Großteil der Funktionen der guten, alten 2er-Version auch auf aktuellen Systemen herstellen kann. Für Archlinux gibt es entsprechende AUR-Pakete, für Faule auch ein eigenes Repository. Fühlt man sich gleich wieder daheim…

Sniffing over the Net – Mit Wireshark und tcpdump auf entfernten PCs sniffen

Ja, ich weiß, Paket-Sniffer sind böse Hackertools und so weiter – wer das Denkt sollte hier aufhören zu lesen und erst eine Prise Praxis zu sich nehmen. Gerade wenn es um das Debuggen von Fehlern in Netzwerkverbindungen geht kommt man nur schwer dran vorbei – wenn man nicht gerade zwischen den Geräten sitzt wird es jedoch schnell ungemütlich. Gehen wir fon folgender Konstellation aus, welche bei mir derzeit aufgetreten ist: Ein Mobilgerät kommuniziert mit einer Webbasierten API über HTTP – der Server steht nicht unter meiner Kontrolle und das Mobilgerät ist selbstverfreilich entsprechend vernagelt. Natürlich könnte man nun einen Monitoring-Port an einem Switch zwischen Mobilgerät und Internetzugang nutzen, aber der liegt weit entfernt und ich müsste zwischen zwei Orten pendeln.

Bisher hieß das für nicht: 2-Schritt-Debugging. Erst verband ich mich auf den (Linux-basierten) Router, fertigte mit tcpdump ein Capture-File an und lud es auf den PC um in Wireshark einen Blick in die Pakete zu werfen. Dank eines Hinweises auf einen Artikel bei Commandlinefu kann ich mir das nun sparen – dank Pipes und ssh lassen sich tcpdump und Wireshark so verschalten, dass ein Live-Capture des Remote-Servers im lokalen Wireshark einläuft. Macht das Ganze wesentlich einfacher…

Ein möglicher Befehl wäre z.B.

ssh root@internetrouter tcpdump -i eth0 -U -s0 -w - 'port 80 and host 192.168.1.2'  | wireshark -k -i -

der letzte Teil des SSH-Commands entspricht den üblichen tcpdump-Filtern – hier sollte man auf jeden Fall drauf achten, dass man den ssh-Traffic nicht mitschneidet – in diesem Fall ists durch die Host/Port-Einschränkung ja ohnehin gegeben, ansonsten sollte ein ’not port ssh‘ helfen.

Gentoo-Look & Feel für die Archlinux-Bash

Auch wenn Gentoo eigentlich mein Haputsystem ist: Auf Netbooks o.Ä. macht das ganze recht wenig Spaß, daher bin ich vor einiger Zeit über Archlinux gestolpert. Auch, wenn die Stabilität und Flexibilität nicht immer an meine Gentoo-Erfahrungen heran kommen, so kann man sich dank sehr großem Binärrepository und den einfach zu erstellenden PKGBUILDS (ähnlich ebuilds) schnell helfen.

Eins, was mir jedoch gewaltig auf den Keks ging war die Bash-Konfiguration: Viele der „Komfortfunktionen“ wie Farbschemata, Historysuche o.Ä. sind unter Archlinux nicht vorhanden oder haben andere Tastenkombinationen – Abhilfe kann wie folgt erfolgen:

Als erstes muss die .bashrc dran glauben – hier sind die meisten Einstellungen drin. Am einfachsten geht das über das Paket aur/gentoo-bashrc, welches unter /usr/share/gentoo-bashrc/bashrc eine Kopie der Gentoo-Konfiguration anlegt. Nach Prüfung kann man diese Datei als persönliche Einstellungsdatei unter /home//.bashrc bzw. /root/.bashrc einspielen. Wichtig: Nicht die Systemweite Datei überschreiben – einerseits würde dies einige Archlinux-spezifische Einstellungen überschreiben und andererseits würde der Updater die Datei nicht mit z.B. neuen Bashcompletion-Einstellungen aktualisieren können.

Was fehlt ist der von mir häufig genutzte Schnellzugriff auf die Bash-History. Damit meine ich, dass wenn ich z.B. „ls“ Tippe mit dem Tasten PgUp und PgDown durch die letzten Befehle, welche mit ls beginnen scrollen kann. Dies läuft über die Datei /etc/inputrc – diese habe ich vollständig durch das Gentoo-Pendant ersetzt:

# /etc/inputrc: initialization file for readline
#
# For more information on how this file works, please see the
# INITIALIZATION FILE section of the readline(3) man page
#
# Quick dirty little note:
#  To get the key sequence for binding, you can abuse bash.
#  While running bash, hit CTRL+V, and then type the key sequence.
#  So, typing 'ALT + left arrow' in Konsole gets you back:
#    ^[[1;3D
#  The readline entry to make this skip back a word will then be:
#    "\e[1;3D" backward-word
#

# do not bell on tab-completion
#set bell-style none

set meta-flag on
set input-meta on
set convert-meta off
set output-meta on

# Completed names which are symbolic links to
# directories have a slash appended.
set mark-symlinked-directories on

$if mode=emacs

# for linux console and RH/Debian xterm
# allow the use of the Home/End keys
"\e[1~": beginning-of-line
"\e[4~": end-of-line
# map "page up" and "page down" to search history based on current cmdline
"\e[5~": history-search-backward
"\e[6~": history-search-forward
# allow the use of the Delete/Insert keys
"\e[3~": delete-char
"\e[2~": quoted-insert

# gnome / others (escape + arrow key)
"\e[5C": forward-word
"\e[5D": backward-word
# konsole / xterm / rxvt (escape + arrow key)
"\e\e[C": forward-word
"\e\e[D": backward-word
# gnome / konsole / others (control + arrow key)
"\e[1;5C": forward-word
"\e[1;5D": backward-word
# aterm / eterm (control + arrow key)
"\eOc": forward-word
"\eOd": backward-word

# konsole (alt + arrow key)
"\e[1;3C": forward-word
"\e[1;3D": backward-word

$if term=rxvt
"\e[8~": end-of-line
$endif

# for non RH/Debian xterm, can't hurt for RH/Debian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line

# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line
$endif

# fix Home and End for German users
"\e[7~": beginning-of-line
"\e[8~": end-of-line

Server-Redesign – watt is?

Soderle, meine heimischen Renovierungsarbeiten schreiten voran und heute musste der alte Stromverteiler dran glauben. Auch wenn die Verdopplung des Platzes eine große Erleichterung darstellt ist es ein Horror für jeden ITler: Der Strom muss aus. Drum drücken kann ich mich nicht, also mache ich das beste draus und gehe das Schon lange fällige Redesign meines Serversystems an. Vor Allem Ausfälle haben dafür gesorgt, dass der Hauptrechner auf mehreren Altsystemen liegt und zu allem Überfluss mangels Platz für Festplatten auf mehrere Gehäuse verteilt ist.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2011/12/wpid-IMAG0641-150×150.jpg

Damit soll nun Schuss sein – und wenn ich grade schon dabei bin wird auch gleich modernisiert:Statt des 200W fressende 19″ Server soll ein neues Board auf Basis des AMD Fusion den Stromzähler etwas schonen. Zwar bieten die Fusion-CPUs nicht gerade üppige Leistung, haben jedoch Hardwarevirtualisierung dessen Fehlen beim vorherigen x345 wohl die meisten Leistungseinbußen gefordert hatte.

Neues Board, neues Netzteil, also mal schnell in die Grabbelkiste gegriffen. Aber welches? Also Messgerät ausgepackt und mit jedem NT den Idle-Verbrauch des Boards gemessen. Am schlechtesten schnitt dabei wie erwartet die 400W-Noname-Büchse ab, welche sich knappe 41W mit einer HDD gönnte. Auf Platz 2 pendelte sich ein 350W-Netzteil des Typs „Rhombutech RT-350“ ein, was mit 37W hinter meinen Erwartungen zurückblieb. Nun verbaut ist ein „LC-Power LC8400P“ das mit etwas über 30W wohl unstrittig das effektivste des Tests ist.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2011/12/wpid-IMAG0642-150×150.jpgEin weiterer Punkt war die Systemplatte. Bisher hatte ich eine SCSI-Platte fürs System, was mit dem mit dem neuen Miniboard flach fällt. Stattdessen habe ich meine Eigenbau-SSD auagegraben: 16GB SD-Karten mit SATA-Konverter sind sicher keine Rennmaschine, aber da außer Logs keine dynamischen Daten drauf liegen ausreichend. Übergangsweise sorgen SATA-Controller und eine weitere NIC für den Betrieb, zukünftig sollen diese Karten auf PCIe-Pendants umgerüstet werden und so die PCI-Sots für ISDN (Asterisk) und Remote Management frei machen. Bild: https://www.adlerweb.info/blog/wp-content/uploads/2011/12/wpid-IMAG0643-150×150.jpgApropos Platten: Wenn man eine Festplatte umbaut und danach einen SMD-Kondensator am Finger hat ist das suboptimal. Zm Glück konnte ich das Ding wieder anlöten – sollte trotzdem eigentlich nicht passieren oO.

Beim OS muss das bisher eingesetzte Gentoo dran glauben: Proxmox soll nun als Virtualisierungsbasis dienen, die NAS und Steuerungsfunktionen wandern dank PCI-Passthrough in VMs. Großer Vorteil: Das ganze System wird modularer und lässt sich so einfacher verwalten – wenn die Leistung nicht reicht wird einfach ein neuer Clusterknoten hinzugefügt.

Ergebnis des Umbaus: Das System hängt jetzt an der Wand, funktioniert und benötigen zum Betrieb nun weniger als die Hälfte der vorherigen Leistung. Geschwindigkeitstechnisch ist erst mal kein all zu großer Unterschied feststellbar, allerdings muss sich das noch zeigen, wenn alle Systeme wieder voll Einsatzbereit sind. Ein kurioses Ergebnis am Rande: Durch die passive Kühlung des Boards ist nun mein Switch das lauteste Gerät im Raum – sehr ungewohnt, wenn man es gewohnt ist üblicherweise quasi Wand an Wand mit einer 19″ Brüllkiste einzuschlafen.

Hallo Gnome 3! (Rant)

Hallo Gnome 3! Schön, dass du dich zu mir gesellt hast. Kennst du noch deinen Vorgänger? Der hat mir gute Dienste geleistet – auf 4 Monitoren verteilt tat er seinen Dienst, die Panels saßen Dank GConf auf dem richtigen „Hauptmonitor“, waren mit allerhand Widgets bestückt und das Home auf NFS hat ihn auch nicht gestört. Gestern dann mein Gedanke – ich könnte ja schnell noch Updaten. Mit dem üblichen „Wird-schon-schief-gehen“-Doppelenter gestartet, im Vorbeiflug noch etwas von Kernel gelesen und einen reboot dran gehängt. Teatime. Nach dem Rückweg hatte der PC neu gestartet und mein Blick erspähte deine ersten Ausläufer – der Loginscreen sieht irgendwie anders aus…

Schnell die Userdaten eingehämmert und … krawautz … „Ihr System ist zu blöd für Gnome, willkommen im Fallback-Mode“ – oder so ähnlich vermeldest du. Der Funktionsumfang ist nahezu nicht vorhanden: Die Panels leer, an hinzufügen von Items nicht zu denken – auch zeigst du sie stur auf dem linken Monitor an – da wo ich nur selten hinschaue. Verschieben erlaubst du mir nicht – warum auch. Ein Blick ins Forum: Mit der Installation der gnome-shell soll sich deine ganze Macht entfalten. Installiert, GDM neu gestartet und… Krach… Kein Bild mehr… WTF?… „Could not acquire name“ – von mit bekommst du jetzt Namen, aber keine netten. Einen Neustart später lande ich wieder im GDM – Logindaten und – na – ein schwarzer Bildschirm.OK, Schnautze voll, vielleicht updatest du ja nur irgendwas, ich geh schlafen.

Neuer Tag, neues Glück, gleicher schwarzer Bildschirm – wohl doch kein Update. OK, ziehen wir mal meine Besonderheiten raus – ein neues Userprofil auf der lokalen HDD darf sich versuchen – mit dem selben düsteren Ergebnis. Tja, wenn du mich nicht ran lässt muss ich wohl fremd gehen und siehe da: Deine fiese Schwester KDE öffnet mir bereitwillig und ohne zu murren alle Fenster zu ihrer bonbonfarbenen Kitschwelt. Ergo: Kein Xorg-Fehler. Nochmal ein Versuch mit Gnome – Gewinner: Keiner. (Verzeit mir, aber mit den 4 Screens im Text-/ASCII-Art-modus kommt langsam Wargames-Feeling auf). Mit passender Wargames-DVD auf dem Laptop nebenan (woho, Grafik!) rüste ich mich für die nächste Runde. Hätten wir noch die 4 Monitore. Reduzieren wir das mal auf ein Haushaltstypisches Maß von einer Guckplatte. Schnell noch GDM neu starten – NIIIICHT. Reboot. Ach schau an – dein GDM hat auch einen farbigen Hintergrund? Der war vorher doch in deiner Lieblingsfarbe – Schwarz. Und nun lässt du mich auch in deinen pachtvollen Neubau…

Ein kurzer Blick – ein längerer Blick – mir fällt nur ein Wort ein: REGRESSION! Die Optik sieht aus als hätte man mir einen angefressenen Obstkorb vor die Nase gestellt. Warum brauch ich meinen halben Bildschirm für den Fensterrahmen? Mich interessieren die Inhalte und nicht das Design außenrum. die UI ist vielleicht für nen Kindergarten eine tolle Sache, aber sicher nicht zum Arbeiten zu gebrauchen. Wollt ihr vielleicht eine Anleitung zum Arsch-Abwischen beilegen oder warum muss jede Pissfunktion auf ein idiotenkompatibles Maß reduziert werden? Nicht jeder vorm PC ist auf dem Bildungsstand eines Zirkusaffen. Flexibilität Funktionen? Brauchen wir nicht – wen interessiert schon die Systemlast im Panel… User sicher nicht… Also löschen wirs gleich für alle, die Bastler interessieren ja keinen. Softwarediktatur FTW! Ich hab ja mit der Umstellung Amarok 1.4 -> Amarok 2 schon einiges mitgemacht, auch da wurden viele Features gedropt, aber es war immerhin in Grundfunktionen noch nutzbar – das kann ich von Gnome 3 nicht sagen. Jetzt, da sich dieser Codehaufen in Stable befindet, habe ich erst mal die Arschkarte – fürs Erste mag ich noch Gnome 2 weiter nutzen können, aber die Updates laufen nicht ewig. Ein Gnome 2 Fork ist nicht in Sicht, meine anderen PCs haben Updateverbot – bleibt nur zeitnah auf etwas Anderes zu wechseln und wieder tagelang Anpassung zu tätigen um am Ende wieder halbwegs das zu können, was schon ausgereift da war. Eine Schande um die jahrelang gereiften Konfigurationsdateien. Gnome 3 mag ja eine schöne Idee sein, aber es ist nicht Gnome. Früher(tm) war es halbwegs schnell, unaufdringlich und Funktionen waren zwar vor DAUs Versteckt, aber trotzdem vorhanden. Ich installiere dann mal grade XFCE und versuche mich daran – tja, liebes Gnome-Team – „Schönen Tag und auf Wiedersehn“. Eventuell wird irgendwann Gnome wieder ein ernstzunehmendes DE, aber das jetzt Veröffentlichte ist ein Komplett neues Projekt und hat nichts mit dem zu tun, für das Gnome einmal bekannt war.

END OF RANT

Disclaimer: Ja, es ist meine Schuld, ja, ich weiß, dass ich forken kann, ja, ich weiß, dass $hier-argument-einsetzen

2GB-Files ext4,xfs,btrfs Benchmark

Da ich derzeit meinen Server aufrüste stellt sich unter anderem die Frage nach dem Dateisystem. Für Root & Homes habe ich bereits auf anderen Systemen ext4 seit längerem im Einsatz, für meine Video-Partition war ich aber nicht ganz sicher. Auf dieser liegen Rohdaten z.B. meines Podcasts oder von Konvertieren von VHS etc, also viele große Dateien. Bisher durfte sich xfs um die Dateien kümmern, mit ext4 soll aber nun xfs Konkurrenz bekommen haben. Da die meisten Tests recht allgemein gehalten waren musste ein eigenes Script ran. Zusätzlich zu xfs und ext4 habe ich noch ext4 mit aktivem „nobarrier“ sowie btrfs getestet. System ist ein AMD Opteron 2358 (Quad 2,4GHz) mit 4GB RAM, Storage ein 3-Disk RAID5 mit ~235MB/s Durchsatz bei hdparm -t.

I/O-Performance

Erst ein Blick auf lesen, schreiben, simultanen Lese-/Schreibzugriffen und löschen. Datenquelle fürs schreiben war ein tmpfs, lesen ging auf /dev/null:

write read rw del
ext4 84,4 114,0 49,3 1.941,5
ext4nb 83,1 197,0 29,9 10.077,5
xfs 54,6 207,0 29,9 109.462,1
btrfs 86,0 200,0 51,9 2.006,6

Wie man sieht hat bei Schreibzugriffen btrfs die virtuelle Nase knapp vor den ext4-Varianten, xfs ist gut ein Fünftel langsamer. Wenns ums Lesen geht kann xfs deutlich punkten, auch wenn btrfs hier knapp dran ist. Der Ausrutscher von ext4 mit Barriers mach für mich zwar keinen Sinn, war aber reproduzierbar. Bei parallelen Zugriffen spielt btrfs wieder sein Asse aus, ext4 mit Barriers ist aber knapp dahinter. Xfs leidet hier unter der schlechten Schreibperformance, Ext4nb – tja, gute Frage… Beim Löschen zahlt sich das XFS-Design wieder aus: Löschen geht fast zehn mal schneller als bei ext4nb – mit Barriers macht ext4 jedoch eine eben so schlechte Figur wie btrfs.

Schaut man nur auf die (theoretischen) Zahlen zeigt sich btrfs schon jetzt als klarer Sieger, jedoch ist es noch in der Entwicklungsphase und kann entsprechend zu Stabilitätsproblemen führen. XFS hält sich bei großen Dateien noch knapp vor EXT4 ohne Barriers, mit Barriers ist die (hier) mangelhafte Lesegeschwindigkeit nicht entschuldbar.

Praxis
Da ich noch ein paar Sachen zu schneiden Habe einfach mal ein Praxistest: Jedes Dateisystem bekommt eine Rohdatei (2GB +/- paar MB) von einem tmpfs drauf kopiert, diese wird erst geprüft (md5sum) in ein anderes Containerformat konvertiert, danach wird von der neu erstellten Datei erneut eine MD5-Summer erstellt, im Anschluss greift eine vorbereitete Schnittliste und speichert eine geschnittene Version. Zum Abschluss wird die Quell- und Zwischendatei gelöscht. Alles nahezu reine I/O-Operationen, da nichts umcodiert werden muss.

ext4nb

xfs

btrfs

ext4

Dateisystem Zeit in Sec.
171
174
187
199

Wie man sieht kann btrfs seinen theoretisch deutlichen Vorsprung nicht halten und fällt auf Platz 3 – hier fehlen wohl noch die nötigen Optimierungen um in der Praxis die guten I/O-Werte auszuspielen. ext4nb schafft es auf den ersten Platz, dicht gefolgt von xfs. Ext4 mit aktiven Barriers, welche auf druck der Community nun Standard sind, liegt auch in diesem Test abgeschlagen auf dem letzten Platz.

Fazit
Wenn es um große Dateien geht sind ext4 ohne Barriers und XFS nahezu gleich auf. XFS ist jedoch fast 14 Jahre älter und ist daher als stabiler anzusehen, zumdem nutzt es vorhandenen Speicherplatz besser aus. Die technischen Grenzen der Dateisysteme sind für aktuelle Rechner eher uninteressant, jedoch unterstützt nur ext4 das nachträgliche verkleinern einer Partition.

Ich für meinen Teil werde für große Dateien damit bei XFS bleiben.