Ksysguard, harddisks und diskstats

Posted on by

Gestern bekam ich von Michael die Frage, wie man denn unter Linux für die “kryptischen” Plattenbezeichnungen in Ksysguard die zugehörigen Partitionen herausfinden könne. Er hatte ein Performance-Problem und wollte sehen, auf welche Platte bzw. Partition das System besonders häufig schreibend zugreift.

Mit “kryptischen” Plattenbezeichnungen waren etwa nachfolgende Einträge im Sensor-Bereich von Ksysguard unter dem Punkt Festplattendurchsatz gemeint :

Ksysguard – Ausschnitt aus dem Sensor-Browser

Festplattendurchsatz

+ 2:0 + 7:0 … … + 7:7 + 8:0 + 8:1 … … + 8:28 + 11:0 + 11:1 (s. Abbdg.)

kys_600

Nun, hinter den Nummern verbergen sich die “major” und “minor” device numbers. Dieses Wissen allein hilft aber auch nicht direkt weiter. Wichtig war Michael ja die Zuordnung dieser Device-Nummern zu den Plattenpartitionen. Letzere sind dem Administrator natürlich besser geläufig.

Auf einem meiner Systeme gibt es z.B. 11 reguläre Linux-Partitionen (Ext3 und ReiserFS) und 3 NTFS-Partitionen in relativ harmonischer Eintracht. Auf die NTFS-Partitionen wird u.a. von VMware-Instanzen aus zugegriffen. Ist man auf einem solchen System an einer partitionsspezifischen Beobachtung des Plattendurchsatzes interessiert, muss man bei Ksysguard schon wissen, wohin genau man schauen sollte.

Zusatz-Informationen aus dem /proc-FS : /proc/diskstats

Woher bekomme ich nun also die Informationen zum Zusammenhang zwischen “device number” und Partition?

Antwort: Aus dem Kernel, oder besser dem /proc – File-System. Moderne Kernel schreiben nämlich statistische Werte für den Plattendurchsatz mit. (Solche Werte werden z.B. von “sar” ausgewertet.) Harddisk-relevante Informationen findet man unter “/proc/diskstats”.

Nachfolgend ein typischer Auszug des Ergebnisses von “cat diskstats” oder “cat /proc/diskstats”:

user@machine:/proc> cat diskstats
8 0 sda 354415 43112 7631712 3704336 269025 782582 8477712 65951972 0 2135876 69736240
8 1 sda1 784 799 0 0
8 2 sda2 4 8 0 0
8 5 sda5 84 520 0 0
8 6 sda6 515 4114 21 168
8 7 sda7 4225 101288 6085 48624
8 8 sda8 826 841 0 0
8 9 sda9 384 778 0 0
8 10 sda10 390174 7518090 1046963 8375680
8 16 sdb 98498 45267 3730694 1115992 194344 559016 6057920 8996952 0 1112700 10123120
8 17 sdb1 2111 2622 0 0
8 18 sdb2 4 8 0 0
8 21 sdb5 36929 293990 72507 580056
8 22 sdb6 384 778 0 0
8 23 sdb7 1078 1093 0 0
8 24 sdb8 436 780 9 16
8 25 sdb9 814 3450 3 16
8 26 sdb10 1877 2374 0 0
8 27 sdb11 95005 3414382 682211 5457664
8 28 sdb12 4309 5184 0 0

Und nun eine Beschreibung der Felder (die ich übrigens großteils dem ersten unten angegebenen Link entnommen habe):

Feld 1 — major device number
Feld 2 — minor device number
Feld 3 — device name (partition)
Feld 4 — # of reads issued
Feld 5 — # of reads merged,
Feld 6 — # of sectors read
Feld 7 — # of milliseconds spent reading
Feld 8 — # of writes completed
Feld 9 — # of writes merged
Feld 10 — # of sectors written
Feld 11 — # of milliseconds spent writing
Feld 12 — # of I/Os currently in progress
Feld 13 — # of milliseconds spent doing I/Os
Feld 14 — weighted # of milliseconds spent doing I/Os

Man sieht:
Hier ist eine Menge Information enthalten – im besonderen eben auch die Zuordnung der Device-Nummern zu den Partitionen.

Datenaufbereitung in Ksysguard

Das Schöne ist, dass Ksysguard einen Teil dieser Informationen in netter Weise aufbereitet. Im besonderen wird einem die Umrechnung in Bytes/s abgenommen. Man kann nun gezielt Ksysguard-Datenblätter für die Parttionen anlegen, die einen besonders interessieren (s. die Abbildung). Zusammenfassende Informationen liefert übrigens auch das Tool “gkrellm”.

Viel Spaß beim Analysieren des Plattenzugriffs !

gkrellm_1

Links

http://ubuntuforums.org/ showthread.php?t=31213
http://www.meinews.net/ festplattenbenutzung-t17640.html
http://utcc.utoronto.ca/ ~cks/space/blog/ linux/ DiskIOStats
http://en.opensuse.org/ Monitor_your_hard_disk_ activity_with_KSysGuard

Generell zum “procfs”:
http://en.wikipedia.org/wiki/Procfs

Kontact – disconnected IMAP – lokale Virenscans

Posted on by

Disconnected IMAP

Da es bei Operationen mit größeren Mailmengen in der Vergangenheit immer wieder Probleme mit einer direkten IMAP-Verbindung von Kmail gab, setzen wir im produktiven Alltag Kontact/Kmail mit einer sogenannten “disconnected imap” – Verbindung ein.

Operationen über viele Mails sind z.B. Suchvorgänge oder Aktionen, die mit konfigurierten Mailfiltern im System zusammenhängen. Klassische Beispiele für Kmail-Filter ergeben sich aus der Einbindung lokaler Virenscanner und von Spamfiltern auf dem Mail-Client.

Die disconnected Imap-Struktur führt zu Replikationen zwischen Server und Client.

  • Vorteil: Operationen auf vielen Dateien (wie z.B. Virus Scans) laufen absturzfrei. Es gibt eine lokale Kopie der Inhalte abonnierter Folder. man kann auch “disconnected” arbeiten.
  • Nachteil: Lange Ladezeiten und intensive Plattenzugriffe beim Start von Kmail, um unsere vielen Mailverzeichnisse zu aktivieren und in temp. Zwischenspeiche rzu laden. Das ist aber ein einmaliger Vorgang – danach geht das Arbeiten flüssig.

Wo liegen die replizierten Mails lokal auf dem Client ?

Ein Systemadministrator wird regelmäßig auch die Mails in Replikationsverzeichnissen der Clients nach Mails untersuchen lassen wollen – und zwar ohne, dass er Kontact/Kmail überhaupt startet. Ferner ist er evtl. an speziellen und ausführlichen Scans ganz bestimmter Verzeichnisse interessiert und möchte für solche Verzeichnisse also “clamscan” oder andere Werkzeuge mit spezifischen Optionen starten. Für ihn ergibt sich dann die interessante Frage:

Wo legt Kmail eigentlich die Kopien der abonnierten Mailverzeichnisse ab? Antwort:
Unter

  • /home/USER/.kde/share/apps/kmail/dimap
  • /home/USER/.kde4/share/apps/kmail/dimap

Wie sieht die Verzeichnisstruktur aus ?

In diesen Verzeichnissen findet man (versteckte) “.”-Ordner für sämtliche “disconnected” IMAP-Verbindungen und deren abonnierte Ordner und Subordner. Die Namensgebung der Folder auf dem IMAP-Server spiegelt sich hierbei in der lokalen Namensgebung trotz bestimmter Zusätze von Kmail wieder. Zu Subordnern führen jeweils die Dot-Verzeichnisse, also die mit dem vorangestellten “.”. Der direkte Mail-Inhalt eines Ordners liegt jedoch immer in den dreigliedrigen Subverzeichnissen des Folders ohne (!) den Dot.

Beispiel: Der Ordner “Ralph” sei unter dem Ordner “Freunde” eingehängt. Zum Mailinhalt von “Ralph” führen dann beispielsweise die Pfade:

  • /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/cur
  • /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/new
  • /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/tmp

Trotz der kryptischen Namensgebung für die Mailfiles kann man dort die einzelnen Mails gezielt mit Kmail öffnen. Warum es diese komplizierte Struktur gibt und wozu sie verwendet wird, kann man leicht erraten. Wir gehen hierauf an dieser Stelle nicht weiter ein.

Wichtiger aber ist, dass man mit dieser Verzeichnisstruktur im Kopf lokale Virenscanner regelmäßig und gezielt auf bestimmte Ordner dieses Baums loslassen kann, ohne Kmail überhaupt zu aktivieren und dessen interne Klamav/Clamav-Filter zu bemühen.

Viel Spaß bei der periodischen Mail-Hygiene!

KDE 4.1 und Nvidia: Fehler bei GTK-Applikationen

Posted on by

Beim Arbeiten mit Openoffice (aber auch mit anderen GTK-Applikationen) treten immer wieder seltsame Artefakte auf, wenn der Input-Cursor im Office-Dokument aktiv ist und man die Maus aus dem Fenster der Applikation hinausbewegt:

Der Controlbar wird bei der Mausbewegung nicht schnell genug upgedated – im Ergebnis treten Verfälschungen der Icon-Farben oder schwarze Rechtecke auf. Manchmal wird das aktive Bild des Desktop im Hintergrund für einen Augenblick schwarz.

Andere User habend den Bug bestätigt. Er scheint generell bei GTK-Applikationen aufzutreten. Ferner scheint er spezifisch für Nvidia Karten und deren proprietäre Treiber zu sein.

Schade eigentlich – das ist manchmal schon störend. Speziell, wenn Entwickler mit Eclipse (auch GTK abhängig) arbeiten, irritiert so was schon gewaltig …..

KDE 4.1 – digitales Problemchen mit KsCD

Posted on by

Beim Ausprobieren von KDE 4.1.2 und seiner Komponenten stößt man schnell auf das Problem, dass die digitale Extraktion von Audio CDs nicht funktioniert.

Fehlermeldung: Keine CD
Das Programm meldet nach Umstellung des Flags “Digitale Wiedergabe nutzen” unter dem Konfigurationspunkt “Extras”, dass keine CD vorhanden sei. Und dies obwohl einen Augenblick zuvor die CD bei analoger Wiedergabe im gleichen Laufwerk noch erkannt worden war! Man stellt sich unwillkürlich die Frage, ob man überhaupt Audio CDs mit digitaler Datenübertragung abspielen kann.

Beruhigt werde ich dadurch, dass ich man einfach mal “xmms”, “amorak” oder “kaffeine” ausprobiere – dort funktioniert die Wiedergabe nämlich, wenn als zugehöriges Backend “xine” eingestellt ist. (Das ist mein persönlicher Default.)

Lösung: Xine als Backend für KDE 4.1 “Phonon”
Also interessiere ich mich dafür, welches Backend eigentlich für den Sound unter dem aktuellen KDE4.1 verwendet wird. Die zugehörige Info finde ich nach etwas Forschungsarbeit unter dem KDE-Hauptmenüpunkt:

“Configure Desktop->Systemverwaltung->Sound->Backend”.

Dort ist das aktuelle Backend für das vielgerühmte “Phonon”-System eingetragen. Phonon wird standardmäßig von allen KDE-Applikationen – so auch KsCD – genutzt. Das Default-Backend ist “Gstreamer”. Leider hat das aktuelle Gstreamer ein Problem mit der digitalen Extraktion, wie einem eine entspr. Recherche im Internet zeigt.

Auf der Suche nach anderen Backends wird man aber schnell fündig: Es gibt bereits ein “phonon-xine”-Backend ! Das zugehörige rpm ist bei Opensuse schon dabei. Nach der Installation taucht dann tatsächlich “Xine” in der Liste der mögl. Backends für Phonon auf.

Wählt man nun “Xine”, so funktioniert danach auch die die digitale Extraktion aus Audio CDs mit KsCD ! Ich wünsche viel Spaß beim Musikhören unter Linux und KDE 4.1!

P.S.: Ich verwende dazu in der Regel “amarok” – auch für Audio CDs ! Das Erlebnis mit KsCD kam nur vom Herumprobieren !

kscd41_1

KDE 4.1.2 – erster Eindruck zur Einsetzbarkeit

Posted on by

Seit 3 Tagen aber ich nun produktiv unter KDE 4.1 auf einem Opensuse 10.3 System. Dabei habe ich regelmäßig Openoffice, den KDE4 PIM Kontact, Dolphin, Konqueror, SmB4K, K3b, Terminals und VMware mit Windows XP eingesetzt. Im Hintergrund werkeln je nach Lust und Laune Compiz/Emerald und Amarok.

Mein Fazit ist:

Trotz immer noch vorhandener Fehler, Ungereimtheiten und Unzulänglichkeiten können Neugierige den Umstieg langsam wagen. Funktional bringt es zwar nichts und spürbar schneller scheint mir KDE4 auch nicht zu sein. Aber das Design ist sehr ansprechend, und man spürt an allen Ecken und Enden, dass sich KDE 4 zu etwas Großem mausern wird – ganz im Gegensatz zu MS Vista.

Richtig gut finde ich die neue Version von Kontact und die erweiterten Möglicheiten bzgl. des Journals, der Notizbücher und der Popup Notes. Das Teil macht jetzt richtig Freude und die neuen Tools sind wirklich nützlich. Allein deswegen lohnt sich der Umstieg – zumal die aktuelle 3.5.10-Version richtige Bugs im Zusammenspiel mit OX5 hat.

Aber es läuft bei weiten noch nicht alles so oder vergleichbar, wie man das von KDE 3.5.10 gewohnt war.

Daher auch der Rat : Installiert KDE 4.1 lieber parallel zu KDE 3.5. Die SUSE RPMs machen einem das grundsätzlich leicht – auch wenn man bei der einen oder anderen Applikation dann auch unter KDE 4.1 letztlich doch wieder zur KDE 3-Version zurückgeht. Schön ist an KDE 4.1 nämlich auch, dass man bei vielen Applikationen die Möglichkeit hat, auch die alte Version von KDE 3.5 zu starten.