Western Digital 4kB Sektoren „we don’t care“

Ein nagelneuer Computer. 2 Western Digital WD10TPVT Festplatten im Linux Software RAID-1 Verbund.
Eine neue openSUSE 11.2 Installation.

Ein Benutzer Erlebnis irgendwo zwischen C16 (auf Datasette warten) und C64 (hätte ich doch die Speichererweiterung gekauft). Immer wieder hängt der Rechner teilweise bis zu 40s. ohne eine Reaktion zu zeigen.

Was war los?
top meldet keine nenneswerte CPU Belastung.
rote Festplatten LED leuchtet ununterbrochen…. -> wir fragen iostat
iostat meldet immer wieder 100% CPU Auslastung durch iowait – Festplatten sind an der Leistungsgrenze…
…da Firefox die Frechheit hatte kurz mal ein paar 100kB wegzusichern 😉

Wenn die Festplatten wegen so einer Kleinigkeit bereits an der Leistungsgrenze operieren, kann man es nicht durch Tuning verbessern – es muss ein grundlegendes Konfigurationsproblem sein… aber welches?!

Nach vielen Stunden stolperte ich über folgenden Artikel:
Problem with WD Advanced Format drive in LINUX (WD15EARS)

Dort wird von ähnlichen Problemen bei einer anderen WD Festplatte berichtet, welche 4kB Sektoren benutzt (die letzten 30 Jahren benutzte man durchgehend 512Byte Sektoren). Hm, benutzt denn meine Festplatte ev. auch diese 4kB Sektoren.

Laut der WD Webseite nicht, denn die 1TB sind auf 1,953,525,168 Sektoren verteilt (512Byte). Ruft man aber die Spezifikationen .pdf Datei auf, dann steht dort klar, dass diese Festplatte bereits mit Advanced Format Technology arbeitet (also doch 4kB Sektoren).

Daher passt die obige Fehlerbeschreibung. 4kB Festplattensektoren sind für derzeitige Linux Systeme der Knaller, denn die Partionierer haben ein ganz anderes (oder besser: altes) Schema im Sinn, so dass sich die Partionsgrenzen überhaupt nicht an die 4kB Ausrichtung halten. Um hier nicht unnötig in Schwafelei auszuarten, kommen nun die zwei wichtigsten Links:

  1. Die Erklärung warum das ganze so ein grosses Problem ist.
  2. Der Workaround, der einem wieder volle Performance bringt.

Die manuelle Repartionierung mit erneuter Installation brachte den Erfolg. Die ganze Sache hat allerdings nicht nur mir viel Arbeit gebracht, sondern wird noch vielen Leuten Kopfschmerzen bereiten. Die Akteure sehen dabei äusserst schlecht aus, allen voran Western Digital

  • WD führt einen durch falsche Hinweise in die Irre (Probleme nur mit Windows XP, andere Betriebssysteme sind ok)
  • WD stellt falsche Informationen ins Netz
  • WD gibt v.a. die Sektoreninformationen nicht richtig an die nachgelagerten Systeme weiter (BIOS,OS)
  • und WD hält es nicht für nötig einen Kernel-/Systemprogrammierer zu beschäftigen der dieses Problem im Voraus unter Linux hätte verhindern können.

Aber auch die Partionierungstools unter Linux sehen schlecht aus.

  • v.a. fdisk benutzt das uralte CHS Layout
  • auch gparted kann erst in der allerneuesten Version, die Sektoreninformation (soweit sie den von der Festplatte richtig weitergegeben wird, s.o.) in ein vernünftiges Partionierungslayout umsetzen.

rsync Problem UTF8 (World vs. Apple)

Wie schon in einem vorangegangenem Artikel erwähnt verwendet Mac OS X leider,leider eine andere Form der UTF-8 Kodierung als der Rest der Welt (Linux,UNIX,Internet,everybody..)

Das Problem ist das Pre-/Postcompositing bei zusammengesetzten Zeichen. Wenn man den Ratschlag des oben verlinkten Artikels beherzigt und es Mac OS X recht machen will und Form D verwendet, stösst man leider auf Probleme mit rsync.

rsync erkennt automatisch die verwendete Encodierung – d.h. auf allen klassischen UNIX Plattformen UTF-8.Kann aber nicht zwischen Form C und D unterscheiden. Das führt dazu, dass bei einem rsync Abgleich von UTF-8 Form D gemässen Dateien auf Linux, Dateinamen mit zusammengesetzen Buchstaben (alle dt. Umlaute) gelöscht und wieder kopiert werden, da rsync diese Dateien als Unterschiedlich erkennt – nicht vom Inhalt, sondern vom Dateinamen.

Man kann zwar mit dem –iconv Flag, den Quell- und Zielzeichensatz bestimmen, aber es gibt eben nur ein UTF-8 – ausser auf Mac OS X, dort gibt es auch UTF8-Mac, was allerdings ein Feature der dortigen iconv Bibliothek ist. Ein rsync von UTF-8 Form D gemässen Dateien funktioniert somit unter Mac OS X um sollte sofern es die Einrichtung (bspw. NFS shares) erlaubt auch verwendet werden.

Leider sieht es nicht so aus, als ob die iconv Verantwortlichen Lust darauf haben den UTF-8 Zeichensatz generell in Form C und D zu trennen. Noch weniger sieht es danach aus, dass Apple auf Form D verzichtet um den 6 Mrd. Menschen auf dem Planeten das Leben leichter zu machen.

Man wird weiterhin immer das kleinste Übel suchen müssen…..

package management unter openSUSE 11.x

Eine historisch begründete Unzufriedenheit mit SUSE Linux Distributionen kommt sicherlich durch den katastrophalen Paketmanager unter SuSE 10.0/10.1 gekoppelt mit Novell’s ZMD und/oder dem stark verbesserten aber noch nicht ganz zufriedenstellenden Paketmanager unter openSUSE 10.2/10.3.

Fairerweise muss man klarstellen, dass dieser Paketmechanismus seit openSUSE 11.0 nun sehr zuverlässig und sehr schnell arbeitet.

Interessanterweise ist das backend das gleiche geblieben. Es handelt sich um libzypp, was das YaST frontend und die Kommandozeilenapplikation zypper bedient. Wie man an im englischen Wikipedia Eintrag nachlesen kann, wurde seit 11.0 der Solver ausgetauscht, was die Performance dramatisch steigerte.

Ich kann das nur für mehrere openSUSE 11.0 Installationen bestätigen – mit 11.2 ist der Paketmechanismus nochmals wesentlich schneller geworden. Zudem können auch kritische Fehler ziemlich schnell behoben werden – am besten auf der Kommandozeile:

zypper refresh

erneuert die Inhalte aller Repositories

zypper verify

Verifiziert die Integrität der Paketabhängigkeiten und schlägt autonom Verbesserungen vor, falls Bedingungen nicht mehr erfüllt werden.

Gerade letzteres benötigte ich, als ein kritisches Update des Paketmanagers selber, durch eine Fehlfunktion des nicht zu empfehlenden SUSE-KDE-Update Applet, schiefging.

Händisch musste ich mit

zypper install

unter zuhilfenahme einer direkten URL zwei Pakete direkt nochmals installieren (mit –force erzwungen) und danach mit zypper verify einen konsistenen Zustand wiederherstellen.

Serielle Schnittstelle ohne internen UART

Im Bereich Messen, Steuern, Sensorik gibt immer noch die serielle Schnittstelle den Ton an.

Dumm nur, dass dieses Randpublikum kaum noch durch Hardwarehersteller bedient wird. Bei Laptops gibt es nur noch selten eine serielle Schnittstelle, bei Desktops teilweise auch nicht – oder zumindest wird kein D-Sub Stecker mehr von aussen zum UART (Serieller Baustein) des Mainboards verbaut.

Die Funktionalität muss daher durch andere Schnittstellen geführt werden und kaum etwas eignet sich schlechter als der Universal Serial Bus. Fast alle USB->Serial Kabel können höchstens ein paar Bytes über die Leitung kriegen. Sobald Timing oder Duplex-Verkehr gefragt ist, sind diese Kabel mit Chipsätzen von Prolific (ganz schlecht) oder FTDI überfordert.

Abhilfe schafft ein Transfer über den PCI Bus, bspw. mit einer ExpressCard.

Die DeLock 66217 ExpressCard34 arbeitet genauso so gut wie die interne Schnittstelle meines Desktop Rechners.
Die Karte benutzt die PCI-Express Verbindung der ExpressCard. In Ihr arbeitet ein Oxford Semiconductor Chip kompatibel zu 16C950 UART

Der Linux Treiber heißt 8250_pci, der aber die Kartenerkennung für diesen Chip erst seit Kernel 2.6.28 besitzt:

Vendor 1415 (Oxford Semiconductor Ltd.)
device c138

Mein openSUSE 11.0 System konnte daher nichts mit der Karte anfangen, erst ein Upgrade auf openSUSE 11.2 brachte das ganze ohne weiteres Eingreifen zum Laufen (8250_pci ist dort statisch in den Kernel einkompiliert und erfordert daher nicht die Kerneleinstellung CONFIG_EMBEDDED, siehe:
http://cateee.net/lkddb/web-lkddb/SERIAL_8250_PCI.html
Dass die Karte, die PCI Verbindung zum ExpressCard Slot benutzt sieht man schon an lspci, welcher den IRQ18 für den UART benutzt.

Die Karte hätte es übrigens in gleicher Bauform auch ein bischen billiger über die USB 2.0 Schnittstelle gegeben – DeLock 66211
Sehr wahrscheinlich mit allen gleiben Defiziten, wie die USB->Serial Kabel…

pdf Annotation tools

Adobe Reader gibt es auf fast allen Plattformen. Zum Lesen von pdf Dokumenten immer noch erste Wahl, was Features und Darstellungsqualität angeht. Leider lassen sich aber mit dem Reader keine Kommentare hinzufügen, ausser dieses Feature wäre explizit in der .pdf Datei freigeschaltet, was quasi nie vorkommt (muss mit Adobe Acrobat Pro unter bestimmten Bedingungen erzeugt worden sein).

Es gibt aber abseits von Adobe einige Programme, die bei jedem pdf Dokument sog. Annotations (Kommentare) und Text Highlights (Markierungen) vornehmen können – diese können dann von anderen pdf Programmen erkannt und gelesen werden.

Hier eine Auflistung der Programme, die derzeit auf UNIX Plattformen pdf Dateien kommentieren und Markierungen setzen können.

Apple Viewer
Mac OS X, proprietär, Bestandteil des Betriebssytems, macht alles richtig
 
Mendeley
Linux, Mac OS X, proprietär aber kostenlos, speichert in interne Datenbank, kann aber exportieren, nicht aber wiedereinlesen
 
Foxit Reader
Linux, proprietär und derzeit kostenlos, das Annotation Tool steht aber derzeit nur in der Windows Variante zur Verfügung, soll aber unter Linux auch kommen
 
Okular
Linux, open source, Bestandteil von KDE, speichert derzeit Annotations nur in eigene Datenbank – der export soll irgendwann kommen, kann aber fremde Annotations einlesen

ColorManagement und LUT’s

Die Wirkung auf das Auge muss bestehen bleiben…

..das ist das Ziel von Farbmanagement, wenn Farben von einem Farbmodell in das andere (z.B. vom Bildschirm zum Drucker) oder von einem Gerätefarbraum in einen anderen (z.B. von DSLR zu Monitor) überführt werden.

Beim Farbmanagement gibt es 4 Teilaufgaben :

  1. Gerätecharakterisierung – wass kann das Gerät
  2. Gerätekalibrierung – Geräteigenschaften konsistent halten
  3. Farbumrechnung – Umrechnung in ein anderes Farbmodell
  4. Farbraumanpassung – Umrechnung in einen nicht gleich großen Farbraum

Unter Mac OS X ist ColorSync die Schnittstelle für alle diese 4 Aufgaben. Kalibrierungsprogramme – z.B. Eye-One Match liefern dieser Schnittstelle Daten, wobei Anwenderprogramme wie bspw. Bibble Daten zur Berechnung an diese weitergeben.

Unter Linux existiert leider kein ColorManagement Modul. Punkt 1+2 kann Argyll übernehmen. Punkt 3+4 muss das Anwenderprogramm übernehmen – oder spezialisierte Module wie LCMS von Scribus.

Während unter Mac OS X „installierte“ ICC Profile sofort in die in der Grafikkarte vorhandenen VLUT (Video Lockup Table) installiert werden – muss dies unter Linux mit dem dispwin Kommando manuell geschehen. Diesese legt man derzeit am besten unter:

/etc/X11/xinit/xinitrd.d/

ab. Zu beachten ist, dass mit dem Display Switch „-d“ auch zweite Monitore angesprochen werden können (genauere Hinweise siehe in diesem Artikel). Dies kann oder muss (Intel GMA950  mit LVDS/TMDS Problematik) man bspw. bei Intel Mobile GPU’s, die auch auf Desktops vorkommen, machen. Bei nVIDIA basierten GPU’s geht derzeit kein seperates LUT, was professionelle Multimonitorbildbearbeitung ausschliest. Auch fehlende XRANDR Unterstützung und das löschen des VLUT’s durch nvidia-settings machen sich negativ bemerkbar.

Eine Besonderheit stellen einige professionelle Geräte aus dem Hause EIZO dar. Dieser verfügen über ein Hardware LUT, welches nur durch die mitgelieferte Software ColorNavigator beschrieben werden kann. Dieser liefert zusammen mit dem ICC Profil äussert zuverlässige Ergebnisse – man kann unter Linux hier auch auf das „installieren“ des ICC Profils verzichten.

Abschliessend noch ein kleines selbstgeschriebenes Testprogramm, welches nur ein Bild auf einem wählbaren Monitor ausgiebt. Durch mehrfaches Starten des Programms kann man bei Multimonitorbetrieb die Unterschiede klar sehen.

screenshot.png

Das Programm liegt als Mac OS X und Linux Version, sowie im Source Code bereit

Qt und jpeg Support auf Mac OS X

Wer auf einem Mac das (mitterweile von Nokia stammende) Qt SDK installiert und in seinem Programm jpeg Support benötigt wird schnell feststellen, dass dieser abhanden kommt, wenn man in seine Applikation Qt-Frameworks einbindet.

QImageWriter::supportedImageFormats() wird .jpg/.jpeg nicht mehr aufzählen.

qconfig.pri welches die Qt Konfiguration beschreibt, listet jpeg Support in QT_CONFIG nicht auf – weder als system-jpeg noch als einkompiliertes Modul. Die Datei befindet sich übrigens (bei Qt 4.5) unter /usr/local/Qt4.5/mkspecs

Die Lösung ist eine plugin Library: libqjpeg.dylib welche sich unter

/Developer/Applications/Qt/plugins/imageformats

befindet. Auch diese Datei muss in das Applikation Bundle mitaufgenommen werden, die Referenz  mit install_name_tool geändert werden, und QApplication muss der plugin Pfad mitgeteilt werden.

Eine genaue Anleitungung dazu findet sich in der ausgezeichneten Qt Hilfe unter dem Stichwort:

Deploying an Application on Mac OS X

kWin Compositing und nVIDIA 185.18.xx Treiber

Es ist soweit! Mit den neuesten stabilen nVIDIA Treibern der Serie 185.18 läuft die OpenGL Beschleunigung auf KDE 4.2 stabil.

Ursache des Problems war u.a. die Antialiasing Einstellung (AA) des nVIDIA Treibers. Sobald diese auf Enhanced Application Setting oder Use Application Settings steht, werden OpenGL Programme die von FSAA Gebrauch machen genau damit gefüttert. Der KDE Desktop bleibt davon völlig unberührt. Bie Vollbildschirmanwendungen – wie Spiele – schaltet kWin jetzt das Compositing zuverlässig ab, so dass bei diesen Applikationen keine Performanceeinbussen mehr zu verzeichnen sind.

Setzt man AA auf Override Settings – so werden OpenGL Programme starke Einbussen  erleiden, solange das KDE Compositing aktiviert ist, das auch kwin – und damit der ganze Desktop – die AA Einstellung verarbeitet. Bei abgeschalteten Compositing macht sich kein Performanceeinbruch mehr bemerkbar.

Quo Vadis Linux – Mac OS X – Sun Solaris …

Die letzte iX veröffentlichte eine Umfrage, welche auf die Benutzung von Linux auf dem Desktop abzielte. Das ernüchternde Ergebnis war, dass sich seit der gleichen Umfrage von 2006 fast nichts veränderte, es wurde sogar ein minimaler Rückgang verzeichnet. Auch andere „Messergebnisse“ oder Prognosen bescheinigen Linux eine Stagnation auf dem Desktop – je nach Land und Methode so zwischen 1 – 3% Marktanteil.

Mac OS X hingegen baut auf dem Desktop seine Stellung weiter aus und kratzt momentan deutschland- und weltweit an der 10% Marke. Kommerzielle Workstation UNIX Varianten, wie Sun Solaris – spielen in diesem Segment keine Rolle mehr. Eher noch dringen Embedded Geräte – mit einem meistens auf Linux basierenden OS – weiter vor.

Die Zukunft von Sun Solaris ist sehr ungewiss. Natürlich spielt es im Enterprise Bereich bei den Hochleistungsservern noch eine grosse Rolle aber Linux rückt auch dort dichter auf die Pelle. Oracle – der neue Besitzer von Sun Microsystems – könnte mit einer eigenen Linuxdistribution die Entwicklungskosten, die Solaris derzeit benötigt, wahrscheinlich deutlich reduzieren. Allerdings würden Sie dann auch die Alleinstellungsmerkmale von Solaris aufgeben – vielleicht bauen Sie deshalb nur die Kompatibilitätsschichten zu Linux weiter aus.

Bei Linux zeichnen sich unterschiedliche Tendenzen ab. Aufgrund der hohen Innovationsgeschwindigkeit und der kurzen Releasezyklen des Kernels wird Linux seine Stellung im SOHO-/Midrange-Server und HPC Bereich weiter ausbauen und zum dominaten Mitspieler in dieser Kategorie aufsteigen.

Im klassischen Desktop Bereich scheint sich aber der Abstand zu Mac OS X und Windows zu vergrössern. Während man sich bei der Linux Foundation noch darum bemüht die Grundlagen des Desktops (Dialoge, etc.) aufgrund mehrerer vorhandener Windowmanager zu vereinheitlichen, ist Mac OS X – aber auch Windows – schon mit sehr mächtigen Frameworks (CoreAudio,CoreGraphics,Windows Presentation Foundation,Windows Communication Foundation) ausgestattet. Diese API’s erlauben Anwendungsprogrammierer sich nur primär auf die Logik Ihrer Applikation zu konzentrieren während man sich unter Linux noch um den ganzen Rest kümmern muss. Natürlich gibt es auch auf dem Linux Desktop diese Ansätze (bspw. GStreamer als Kooperation zwischen Gnome und KDE), diese sind aber noch in der Anfangsphase – nicht immer ausgereift und es gibt v.a. keinen Hinweis darauf wie diese Technologielücke in der nächsten Zeit geschlossen werden sollte.

Damit wird sich Linux als Desktop bei Privatnutzern trotz der Stabilitäts- und Sicherheitsvorteile in der nächsten Zeit nicht durchsetzen können. Anders sieht es in gewissen Enterprise Bereichen aus. Dort wo das Betriebssystem quasi nur als Programmstarter benutzt wird und die überschaubaren Applikationen mit maximaler Stabilität und Performance laufen müssen, ist Linux im Vorteil – sofern die Applikationen die Plattform unterstützen.

Noch besser sieht es im bei Spezialanwendungen oder im Embedded Bereich aus. Dank der flexiblen Konfigurationsmöglichkeiten die Windows und Mac OS X einfach nicht bieten, ist dort Linux mit Abstand die beste Wahl. Da es sich dort auch schon seit einiger Zeit im harten Einsatz bewährt hat, wird sich die Verbreitung von Linux auf solchen Systemen in nächster Zeit beschleunigen.

Der Mac OS X Zug fährt mit konstanter Geschwindigkeit weiter. Nach der 10% Hürde wird es Apple in den nächsten Jahren schaffen 20% des Desktop Marktes für sich zu beanspruchen. Auch wenn einige Entscheidungen aus dem Hause Apple schwer nachzuvollziehen sind (Vernachlässigung der Pro Sparte im Hardware Bereich) bleibt Mac OS X das beste Desktop System unserer Zeit. Die Verschmelzung der klassischen Mac OS GUI’s mit der UNIX Technik von NEXT brachte ein System hervor, welches aus mehreren Welten das Beste vereinte und auf dem Desktop technisch wie ergonomisch das Feld mit grossem Abstand anführt.

Wenn man übergreifend den ganzen IT Kuchen betrachtet, werden die Stücke die auf UNIX Technologie basieren – und damit sind nicht die imkompatibel in Windows hereingewanderten Komponenten gemeint 🙂 – kontinuierlich grösser.

XDG: Speicherort für Konfigurations- und Datenfiles

freedesktop.org ist das Standardisierungsprojekt um Desktopeinstellungen unter Linux für alle (Mainstream)Desktops zu vereinheitlichen. Gemeint sind v.a.

  • KDE
  • Gnome
  • XFCE

Dies betrifft bspw. das Anlegen eines Menüs unter KDE, was man bei einem Wechsel auf Gnome immer noch sehen möchte.

Das Projekt hatte mit diesen Bestrebungen Erfolg – entscheiden sind dabei die XDG (vom Namensvorgänger der Organisation: X Desktop Group).

$XDG_DATA_HOME (default: $USER/.local/share ) 
$XDG_CONFIG_HOME (default: $USER/.config )
$XDG_DATA_DIRS (default: /usr/local/share:/usr/share )
$XDG_CONFIG_DIRS (default: /etc/xdg )

Die beiden letztgenannten Verzeichnisse sind die globalen, in denen Default- oder Fallbackeinstellungen abgelegt werden. Die beiden erstgenannten sind die Benutzereinstellungen.

Wichtig bei allen XDG-kompatiblen Desktops ist die Fähigkeit, die Reihenfolge der Verzeichnisorte auszuwerten, sowie die Voreinstellungen der Umgebungsvariablen bei Nichtvorhandensein zu kennen.