Linux SSD partition alignment – problems with external USB-to-SATA controllers – II

In my last article
Linux SSD partition alignment – problems with external USB-to-SATA controllers – I
I wrote about different partition alignments parted and YaST's Partitioner (Opensuse) applied when one and the same SSD (a Samsung 850 Pro) was attached

  • to external USB-to-SATA controllers and the USB bus of a Linux system (1 MiB-alignment: start sectors as multiples of 2048 logical 512 byte blocks)
  • or directly to an internal SATA-III-controller of a Linux system (alignment to multiples of 65535 logical 512 byte blocks).

We saw that different controllers led to the detection of different disk topology parameters (I/O limits) by the Linux system via the libblkid library. For one and the same SSD different values were reported by different controllers e.g. for the following parameters (I/O Limits data) :

physical_block_size,    minimum_io_size,    optimal_io_size

We saw in addition that even different Linux disk tools may report different values; e.g. fdisk showed a different value [512 byte] for the "optimal_io_size" for the SSD on the SATA bus than e.g. lsblk and parted [0].

Guided by a Red Hat article https://people.redhat.com/msnitzer/docs/io-limits.txt we came to the conclusion that at least parted and YaST's Partitioner use heuristic rules for its alignment decisions. The rules take into account the values for disk "I/O Limits" parameters. They are consistent with a default of "optimal" for the alignment parameter of parted and provide a decision when "the value for "optimal_io_size" is found to be zero. By applying these rules we could explain why we got different partition offsets and alignments for one and the same disk when it was attached to different controllers.

But this insight left us in an uncomfortable situation:

  1. Should we cling to the chosen settings when we use the SSD on external controllers, only? Can we partition SSDs on an external USB-to-SATA controller and move them later directly to a SATA-bus without adjusting partition borders? We saw that "parted" would complain about misalignment when SSD partitions were prepared on a different controller.
  2. As many people discuss the importance of partition alignment for SSD performance - will we see a noticeable drop in performance when we read/write to "misaligned" partitions?
  3. We saw that at least a JMicron controller indicated a bundling of 8 logical 512 byte blocks into a 4096 byte (fake?) "physical block". Another question might therefore be what happens after an installation and something is written by Grub to the first sector of a disk with GPT layout - and maybe assuming some wrong disk topology? This is not so far fetched as one may think; see the third link at the bottom for a disaster with an MBR.

I cannot answer all these questions in general. But in this article I will at least look a bit into performance issues and answer the last question for my test situation.

Weiterlesen

Eclipse Photon 2018-09 für PHP – endlich gute Content Assist Performance

Ende August war ich auf die "R"-Version von Eclipse Photon umgestiegen. Der Start der IDE erwies sich zwar als elend langsam; aber immerhin erschien mir das Zusammenspiel mit GTK3 gegenüber Eclipse Oxygen deutlich verbessert. Auch eine Java10-Runtime-Umgebung ließ sich gut verwenden.

Etwas hat mich jedoch zunehmend bei der Arbeit behindert:
Bei großen PHP-Projekten erwies sich die Content-Assist-Funktion [CA] des PHP Editors als bodenlos langsam. Wenn man den Heap beobachtete, so wechselte der während des Wartens auf eine CA-Antwort ständig die Größe. Gegenüber den in Eclipse ablaufenden Hintergrundsprozessen (Neu-Indizierung vieler Files? Update diverser Oberflächenelemente? ...) kam die CA-Funktionalität offenbar erst mit geringer Priorität zum Tragen. Das war völlig irregulär. Mal erhielt man eine Anwtort zu einer lokalen Variable sofort; mal musste man 5- 6 Sekunden warten. Die Meldung "Computing proposals ...." ging mir zunehmend auf den Zeiger. Wer will beim Tippen schon 5 Sek warten, bis der erste Vorschlag kommt? Leider hat keine der angebotenen Optionen unter "Preferences >> PHP >> Editor >> Content Assist" viel geholfen. Auch nicht zur "asynchron Code Completion". Ich war kurz davor, wieder auf Oxygen zurück zu gehen.

Heute habe ich heute aber die neue "September-Version von Eclipse ( "eclipse-php-2018-09-linux-gtk-x86_64.tar.gz" ) installiert, Updates der "webkit2"-Bibliotheken unter Opensuse vorgenommen und auch die "~/.eclipse"-Eintragungen neu erstellen lassen.

Und siehe da: Die Performance der CA-Funktionalität im PHP-Editor ist nun wieder so wie in alten Zeiten. nach nun 6 Stunden Arbeit kann ich sagen: Das Programmieren mit PHP und Eclipse macht wieder Freude ....

Libreoffice 6.0 und 6.1 Draw unter KDE/Plasma und Gnome – mit gtk3-Unterbau viel zu langsam

Einer meiner treuen Begleiter war Libreoffice Draw. Aber nach dem Upgrade auf Opensuse Leap 15 hatte ich damit beim Arbeiten mehr Frust als Lust. Ich muss z.Z. Skizzen einer Art neuronaler Netzwerke erstellen. Da kommen mal schnell 50 bis zu über hundert Einzelobjekte zusammen, die in großer Anzahl durch "Verbinder" aneinander gekoppelt werden müssen.

Das aktuelle Draw der Libreoffice Versionen 6.0 und 6.1 ist unter einem KDE-System mit GTK3 dafür aber viel zu langsam:

Klickt man auf das Symbol für "Verbinder" in der Leiste für Zeichnungstools, so dauert es auf hochauflösenden Schirmen (2K bis 4K) und bei komplexen Zeichnungen zwischen 4,5 und 8 Sekunden, bis die Zeichnung auf eine Darstellung mit allen Connector-Punkten der Objekte wechselt.

Ich habe nun wahrlich kein langsames System; auch die Speichereinstellungen für LO habe ich bereits (mühsam; s.u.) nach oben gesetzt. Während des Darstellungswechsels für Verbinder geht die Belastung des genau einen CPU-Kerns, den LibreOffice leider nur nutzt, kurzzeitig auf 100%.

Bei einer normalen "LO 6"-ImplementierungInstallation ist das Paket "libreoffice-gtk3" installiert; GTK3 wird dann automatisch gezogen. Ein gezielter Start für GTK3 ist im Terminal mit "SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice &" möglich. Nun kann man sich zusätzlich das Paket "libreoffice-gtk2" installieren und den Aufruf zu "SAL_USE_VCLPLUGIN=gtk_kde5" abändern.

Ein nachfolgender Test zeigt, dass die Zeiten beim Einsatz von GTK2 im Bereich von 2-3 Sek. liegen! Damit kann ich gerade noch leben. Weitere Tests offenbaren Folgendes:

Die Geschwindigkeit, mit der Draw die Anzeige von Connector-Punkten aller Objekte auf den Schirm bringt, hängt vom Zoomfaktor ab, mit der man sich das odg-Dokument anzeigen lässt; kleine und große Zoom-Faktoren machen den Umgang mit Verbindern bisweilen deutlich schneller.

Wer also große Diagramme mit vielen Objekten und Verbindern zeichnen will, sollte im Umgang mit Libreoffice 6.1 auf GTK3 verzichten. Zumindest unter KDE. Das kann man dort entweder durch den Aufruf

SAL_USE_VCLPLUGIN=gtk_kde5 libreoffice &

erreichen, oder aber indem man das Paket libreoffice-gtk3 deinstalliert und dafür das Paket "libreoffice-gtk2" installiert (neben libreoffice-qt5). Ein Verzicht auf gtk2 und gtk3 sowie eine alleinige Installation von libreoffice-qt5 führt vom Layout her übrigens in die GUI-Steinzeit. Ob das so richtig ist, mag ich im Moment nicht einmal recherchieren.

Nun habe ich auch das Rendern über OpenGL ausprobiert - funktioniert leider nicht => Schwarze Menüs. Ansonsten wäre der Aufbau der Zeichnung selbst etwas schneller ...
Tests unter Gnome und LXDE brachten leider die gleichen Ergebnisse.

Ich hoffe auf Updates - und darauf, dass sich die LO-Entwickler endlich mal Gedanken darüber machen, an welchen Stellen sich Multithreading lohnen würde. Der Umgang mit Verbindern wäre da ein erstes gutes Betätigungsfeld. So wie der Stand im Moment im Zusammenspiel von Draw mit GTK3 aussieht, sind LO 6.0 und 6.1 jedenfalls eine Enttäuschung.

P.S. zum Thema Menü-Änderungen: Hinzu kommt der sich auch unter Kontact/Kmail ausbreitende Ehrgeiz von Maintainern, bewährte Menüpunkte für Programm-Einstellungen, die die Performance und die RAM-Nutzung einer Applikation beeinflussen, aus dem normalen Menübereich in eine völlig unübersichtliche und undokumentierte globale Parameter-Konfiguration zu verbannen. So geschehen bei Kmail; so geschehen bei LO.

Liebe Leute: Seit wann bieten wir dem User unter Linux weniger Optionen an? Und seit wann wird Bewährtes und Verständliches in der Menüstruktur zugunsten unverständlicher und undokumentierter Parameter-Kaskaden aufgegeben? Bitte liebe LibreOffice-Teams: Hört mit diesem falschen Ehrgeiz an Options-Verlagerung und -Vernichtung auf ... und kümmert euch lieber mal um die Performance.

Nachtrag 19.10.2018 zur Performance: Es ist inzwischen insgesamt ein wenig besser geworden (LO 6.1.3); dennoch geht das Arbeiten mit Verbindern in DRAW unter GTK2 immer noch schneller von der Hand als unter GTK3.