sshfs und die Rote Null

Heute hat mir sshfs mal ein Ei gelegt:

Filesystem Size Used Avail Use% Mounted on
[...]
wusel@death.uu.org: 1000G 0 1000G 0% /home/wusel/death
wusel@hdtvdr.uu.org: 0.0K -0.0K 0.0K 140% /home/wusel/hdtvdr

-60% freier Platz, das ist jetzt doch mal relativ viel wenig frei. Spannend ist auch die Ausgabe von »df -k« statt »df -h«:

Filesystem 1K-blocks Used Available Use% Mounted on
[...]
wusel@death.uu.org: 1048576000 0 1048576000 0% /home/wusel/death
wusel@hdtvdr.uu.org: 0 -0 0 140% /home/wusel/hdtvdr

Nun bin ich baff. Gut, ich habe ja schon was von schwarzen und roten Nullen gehört, aber bei Filesystemen ist mir dies eher neu – zumal eine negative Anzahl genutzter Blöcke ja bedeuten würde, daß man erst was abspeichern müßte, um das Filesystem leer zu bekommen‽ (Und nein, das Ziel-FS ist ein normales ext3, keine experiementellen Geschichten wie zfs oder überbuchtes SoD-NAS …)

ntp1.sda.t-online.de annektiert

Auf einen groben Keil gehört ein grober Klotz; nachdem T-Home/-Online wieder einmal über einen halben Tag unfähig war, ihren bekifften NTP-Server »ntp1.sda.t-online.de« zu bändigen – weshalb meine T-Home X301T nach Trennung vom und Rekonnektierung ans Stromnetz nicht booten wollte – habe ich nun die IP auf das Interface meines Routers gebunden, über den die X301T ins Netz geht:

root@gw.uu.org:~ # ifconfig eth1:5 195.145.119.188 netmask 255.255.255.255 up
root@gw.uu.org:~ # ntpq -p 195.145.119.188
remote refid st t when poll reach delay offset jitter
==============================================================================
+ptbtime1.ptb.de .PTB. 1 u 112 256 377 67.908 -20.409 3.001
*zit-net2.uni-pa .DCF. 1 u 43 256 377 71.126 -24.551 1.598
LOCAL(0) LOCAL(0) 10 l 29 64 377 0.000 0.000 0.008

Nun bootet das Schätzchen endlich wieder klaglos, keine unbeantworteten NTP-Anfragen behindern es mehr — und falls dermaleinst doch, kann ich das beheben, wozu T-Offline ja augenscheinlich weder Muße hat noch Überwachung … Narf.

linux/types.h vs asm/types.h

*sigh* Nachdem ich mit dem vdrdevel-Zweig aus dem e-tobi-Repository nicht wirklich klar gekommen bin, bin ich nun dem Rat von Tobias Grimm gefolgt und baue mir »normale« vdr-Pakete für mein Ubuntu 8.10 auf Basis der Vorarbeit von Grimm und anderen: Ich habe das vdr-1.6.0-Quellpaket geholt, wie von Tobias Grimm per Mail vorgeschlagen mittels des Debian-Maintainer-Tools »uupdate« auf die Upstream-Version 1.7 aktualisiert (vorher den 1.7.0-tarball von cadsoft geholt) und wollte dann die notwendigen Patches für Multiproto- bzw. S2API gemäß Schema F einpflegen. Soweit, so theoretisch einfach ;-)
Während die Umwandlung der Patches für vdr 1.7.0 (vgl. bei free-x) mittels dpatch einfach war und sie sich auch wunderprächtig applizieren liessen, machte das Hinzufügen der Optionen für die Kernel-externen Treiber (ich nutze diesmal s2-liplianin) schon mehr Kopfzerbrechen. Meine Lösung ist dieser zusätzliche dpatch:

root@hdtvdr:/usr/local/src/hd-vdr# cat vdr-1.7.0/debian/patches/81_Make_config-S2API.dpatch
#! /bin/sh /usr/share/dpatch/dpatch-run
## 81_Make_config-S2API.dpatch by <root@hdtvdr.ltsp>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: S2API patch (DVB-S2) for Make.config
@DPATCH@
*** vdr-1.7.0/Make.config 2009-03-03 20:36:55.000000000 +0100
— /tmp/Make.config 2009-03-03 20:35:06.000000000 +0100
***************
*** 26,28 ****
— 26,37 ----
# memory leaks in the plugin libs
DEFINES += -DVDRDEBUG
endif
+
+ DVBDIR = /root/s2-liplianin/linux
+
+ ### You don't need to touch the following:
+
+ ifdef DVBDIR
+ INCLUDES += -I$(DVBDIR)/include
+ endif
+ 

Damit wurde dann auch angefangen, zu kompilieren – kein Abbruch mehr, weil die DVB_API_VERSION 3 (Ubuntu-Kernel (3.0) als auch Multiproto (3.3)) und nicht 5 ist –, leider brach der Compiler dann später ins Essen: »__u8 does not name a type« mit Hinweis auf frontend.h und dmx.h. ¡Mierda!
Hier brachte dann ein »diff -c /usr/include/linux/dvb/frontend.h /root/s2-liplianin/linux/include/linux/dvb/frontend.h«, also ein Vergleich der Kernel-Sourcen mit denen aus dem s2-liplianin-Zweig, die Aufklärung: Augenscheinlich ist 2009 bei Kernel 2.6.27 nicht mehr linux/types.h für derlei Treiber zu inkludieren sondern asm/tyes.h. Mit einer marginalen Änderung im s2-liplianin-Zweig lief dann auch der Buildprozess durch:

*** /root/s2-liplianin/linux/include/linux/dvb/frontend.h 2009-03-03 21:25:10.000000000 +0100
— /tmp/frontend.h 2009-03-03 21:24:49.000000000 +0100
***************
*** 26,32 ****
#ifndef _DVBFRONTEND_H_
#define _DVBFRONTEND_H_
! #include <linux/types.h>
typedef enum fe_type {
FE_QPSK,
— 26,32 ----
#ifndef _DVBFRONTEND_H_
#define _DVBFRONTEND_H_
! #include <asm/types.h>
typedef enum fe_type {
FE_QPSK,

So, nun werde ich die Früchte dieses Abends probieren, also meine Pakete installieren und schauen, ob jener VDR überhaupt anstartet ;)

root@hdtvdr:/usr/local/src/hd-vdr# ls -la *.deb
-rw-r–r– 1 root root 872738 2009-03-03 21:24 vdr_1.7.0-1hdtv1_i386.deb
-rw-r–r– 1 root root 1281536 2009-03-03 21:24 vdr-dbg_1.7.0-1hdtv1_i386.deb
-rw-r–r– 1 root root 306658 2009-03-03 21:23 vdr-dev_1.7.0-1hdtv1_all.deb
-rw-r–r– 1 root root 75674 2009-03-03 21:24 vdr-plugin-examples_1.7.0-1hdtv1_i386.deb
-rw-r–r– 1 root root 35470 2009-03-03 21:24 vdr-plugin-sky_1.7.0-1hdtv1_i386.deb

 
Dann ginge es an die gewünschten Plugins, diese sind natürlich ebenfalls einmal durchzubauen, da es ja keine »normale« vdr-Version 1.7.0 von e-tobi.net gibt.
Ich glaube, daran breche ich mir morgen die Wurstfinger ;) An dieser Stelle nochmals der auch schon per Mail kommunizierte Dank an Tobias Grimm für das Schubsen auf den rechten Pfad.
Nachtrag: Gegen »error: linux/compiler.h: No such file or directory« gibt es ebenfalls Abhilfe, in meinem Fall:

cp /usr/src/linux-headers-$(uname -r)/include/linux/compiler.h
/root/s2-liplianin/linux/include/linux/

painseeker-Update (HDTV-VDR)

Lalala. Rund ein Monat ist seit meinem ersten Anlauf ins Land gegangen, und wenngleich ich einen HDTV-tauglichen VDR 1.7.0 samt VDPAU-Ausgabe über den nvidia-8200 IGP des Asus-Barebones V3-M3N8200 recht schnell – nach einer stattlichen Anzahl mutiger Beschwörungsformeln (»./configure && make && make install«) – an den Start bekommen habe: da der Wunsch nach mehr besteht als nur einen VDR laufen zu lassen, MythTV, Freevo, XBMC und wie sie alle heißen aber einen Rattenschwanz an Abhängigkeiten grade auf die multimedialen Libraries, die just für VDPAU aus CVS & Co. gezogen werden müssen, haben, war das Ergebnis recht schnell unspaßig. Tat die Mediacenter-Oberfläche, rannte das VDPAU-gepatchte Libraries erwartende VDR-Umfeld nimmer (oder nur ohne VDPAU, d. h. bei HD-Content mit >50% CPU-Last auf dem 2,7 GHz-DualCore K10-Athlon), lief die VDR-Ausgabe (zumindest auf dem 22-“-Test-LCD mit 60 Hz) super flüssig, spuckten Mediacenter-Teile ins Essen. Und dies alles noch ohne auch nur ein »apt-get update && apt-get upgrade« …
Ergo: Ubuntu 8.10 und ein DVB-S2-tauglicher VDR mit HDMI-Ausgabe und VDPAU-Unterstützung »zu Fuß« ist nur als dedizierte Lösung oder als Dauerbaustelle aus meiner Sicht ratsam; sicherlich könnte man ffmpeg und die ganzen sonstigen Libraries von Updates ausschließen, aber mittel- bis langfristig ergeben nur paketierte Lösungen Sinn.
Zum Glück hat sich da in der Zwischenzeit einiges getan:

Dieses Mal – ich habe Ubuntu 8.10 auf einer USB-Disk auf dem Zielrechner neu installiert, was bis auf die Notwendigkeit, jenes als Bootlaufwerk mittels F8 aus dem BIOS heraus auszuwählen (in den Boot-Einstellungen des BIOS läßt sich nur der ingetrierte Cardreader als Bootdevice auswählen, nicht aber gefundene/andere USB-Platten), erstaunlich schmerzfrei und flott klappt – mußte ich allerdings auf einen anderen Thread zurückgreifen, um beide DVB-S2-Karten – TeVii S460 DVB-S/S2 und KNC1 DVB-S2-Clone – eingebunden zu bekommen:

hg clone http://mercurial.intuxication.org/hg/s2-liplianin/
cd s2-liplianin/
make KERNELRELEASE=$(uname -r)
make KERNELRELEASE=$(uname -r) install

Ich bin gespannt, wie vdr-1.7.0 damit zurecht kommt; besagtem Thread zufolge – was ich ohne Übersetzung anhand der Kommandozeilen überreiße –, sollte vdr-1.7.0 auch mit diesem Treiber arbeiten können …

WTF?

top - 11:29:07 up 12 days, 2:20, 6 users, load average: 0.81, 0.98, 0.82
Tasks: 131 total, 2 running, 129 sleeping, 0 stopped, 0 zombie
Cpu(s): 34.8%us, 7.8%sy, 0.0%ni, 56.9%id, 0.0%wa, 0.5%hi, 0.0%si, 0.0%st
Mem: 1811800k total, 1654852k used, 156948k free, 162428k buffers
Swap: 2224960k total, 1812k used, 2223148k free, 532388k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6144 wusel 20 0 628m 330m 34m R 39.0 18.7 3299:27 firefox
6 root 15 -5 0 0 0 S 3.5 0.0 233:43.29 events/0 

Mal ernsthaft, liebe Feuerfuchs-Coder: Warum in Dreiteufelsnamen frißt der Browser unendlich viel CPU, wenn er grade mal vier Fenster anzeigen soll (4 Fenster mit insges. 32 Tabs; davon zwei Fenster miniaturisiert)? Kann man das nicht anders lösen, in den nicht sichtbaren Fenstern bzw. zumindest den nicht »offenen« Tabs das ganze JavaScript-, Flash-Gedöns und sonstige zweckfreie Resourcenfresser nicht bearbeiten?
So ist Firefox jedenfalls der primäre Energieverschwender hier — die gezeigten 38% CPU sind eher die untere Grenze, das geht auch schon mal auf 60+ hoch :(