Posts by frostschutz

    Hallo,


    da heute im Adventskalender ja Domains angeboten werden habe ich heute für drei Domains DNS editiert. Dabei sind mir zwei Dinge aufgefallen:


    1)


    Wenn ich versuche einen MX Eintrag zu ändern in einen A / AAAA / sonstwas, dann wird das mit einer Fehlermeldung quittiert selbst wenn der Eintrag richtig ist. In dem Moment wo man statt MX irgendwas anderes ausgewählt hat, verschwindet das Eingabefeld für MX-Priorität. Der darin enthaltene Wert scheint aber immer noch Beachtung zu finden, die Fehlermeldung ist dann Fehler: Eintrag ungültig: test A 10 1.2.3.4 und die 10 war eben das was im nicht mehr sichtbaren MX-Priorität-Feld stand. Um den Eintrag doch editieren zu können muss ich wieder MX auswählen, in das Priorität-Feld eine 0 eintragen (leer lassen geht auch nicht), und dann wieder zurück zu dem was ich eigentlich haben wollte.


    Im gleichen Schritt gehen auch alle anderen Einträge/Änderungen verloren so daß man nicht einfach nur diesen einen Fehler korrigieren und weitermachen kann, sondern alles wieder neu schreiben muss. Solange das Formular Eingaben wegen Fehlern verliert ist es also besser jede Änderung einzeln zu speichern...


    2)


    Das ist mehr dem Perfektionismus geschuldet, aber wenn man neue Einträge hinzufügt landen die irgendwie wie Kraut und Rüben in der DNS-Liste und nicht entweder a) in der Reihenfolge in der ich hinzugefügt habe oder b) irgendwie sortiert. Wegen der Sortierung habe ich auch erst probiert Einträge zu editieren statt einfach zu löschen und neu hinzuzufügen.


    Konkretes Beispiel, in einem Schritt neu hinzugefügt:


    Code
    1. 01 A 1.2.3.4
    2. 02 A 1.2.3.4
    3. 03 A 1.2.3.4


    Ergebnis:


    Code
    1. ... Alte Einträge...
    2. 01 A 1.2.3.4
    3. ... Alte Einträge...
    4. 03 A 1.2.3.4
    5. 02 A 1.2.3.4


    Also 01 irgendwo zwischendrin und 03 02 falsch herum. Weiß nicht wie das kommt, werden da alte gelöschte Slots wiederverwendet oder sowas?


    Technisch spielt es ja weiters keine Rolle, aber solange die DNS Einträge von Menschen editiert werden wäre eine sortierte Darstellung der Einträge schön, oder gar die Möglichkeit im Formular die Reihenfolge der Einträge selbst ändern zu können...


    Gruss
    frostschutz

    Diese haben durchaus verschiedene physikalische CPUs, weshalb wir hier auch nur virtuelle CPUs bewerben.


    Daß es virtuelle CPUs sind wird nicht immer so 100% klar, in der Produktbeschreibung steht "Prozessorkerne: 2", nicht so wie beim Root S wo da explizit noch "virtuell" dahintersteht. (Natürlich steht "dediziert" auch nirgends). Will auch gar nicht meckern, bin ja froh daß es den Adventskalender gibt. :thumbsup: (habe hier nicht zugegriffen, schaue aber jeden Tag rein, vielleicht ist ja auch mal was für mich dabei)

    Speichern bei uns einige Daten in einer Ramdisk da es doch wichtig ist das auf diesen Daten schnell zugegriffen werden kann. Dank dem doch abrupten Update sind nun Daten seit heute um 12 Uhr weg...


    SSKM.


    Wenn die Daten wichtig sind musst du dafür sorgen, daß sie gesichert werden und nicht nur flüchtig im RAM liegen.


    Darüber hinaus wurden die Server ja nicht unerwartet per Stromausfall/Reset ausgelöscht, sondern sauber heruntergefahren. Services haben hier die Gelegenheit noch Daten zu sichern.


    Da solltest du deine Lösung für die Zukunft unbedingt nachbessern.

    Kann ich die zur Verfügung gestellten CD-ROM-/DVD-Images wie
    z.B. "Ubuntu 14.04 Server 64 Bit" nur auf einem "Root-Server L Generation
    6" oder auch auf einem "Root-Server M Generation 6" nutzen?


    Du installierst dir einen Bootloader auf die Festplatte. Wenn du nicht weißt wie das geht, machst du halt zuerst irgendeine Image-Installation.


    Dann lädst du dir Kernel und Initrd von hier: Index of /ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64


    Und dann bootest du das und installierst wie gewohnt. Die Pakete werden dann nicht von CD sondern übers Internet geladen, ansonsten dürfte es gleich sein...


    Oder aber du freundest dich mit debootstrap an.

    Du brauchst ein besseres Mikrofon (oder ich bessere Ohren) oder einen anderen Audio-Codec. Selbst ein 0815 USB-Mikrofon um 10-20€ sollte das besser hinbekommen. Deine Aufnahme klingt nach Onboard-Mikrofoneingang ohne Mic-Boost...


    Um herauszufinden was beim Befolgen der Wiki-Anleitung nicht geklappt hat, wäre es interessant den ganzen Vorgang im Terminal mal festzuhalten (per 'script' o.ä.). fdisk könnte Probleme machen, es gibt inzwischen ja auch zig verschiedene fdisk-Versionen (mit und ohne GPT-Unterstützung, mit und ohne automatisches Partitions-Alignment, ...), da muss man sich eben anpassen. Das Rettungssystem macht Anfängern vielleicht auch Probleme, weil man hier erstmal selbst sich drum kümmern muss daß es überhaupt bootet (Network steht nicht automatisch in der Liste und schon gar nicht an 1. Stelle - bei dir auch nur auf Platz #2).

    parted nimmt leider schräge Einheiten beim print, die es falsch aussehen lassen obwohl es richtig ist.


    Wenn du Partitionsalignment mit parted anschauen willst, nimm lieber:


    Code
    1. parted /dev/xyz unit mib print free
    2. parted /dev/xyz unit s print free


    Wenn du glatte MiB siehst bzw. Sektoren vielfache von 2048, dann passt es. Falls es eine erweiterte oder bios_boot Partition gibt: Es zählt nur primary und logical.


    Edit: Ups, ich hab dich glaub eh falsch verstanden, dir gings nicht ums Alignment... sorry :)


    Wenn es VirtIO ist (/dev/vda) dann kannst du problemlos im Betrieb neue Partitionen hinzufügen, der Kernel sieht diese sofort. Einzig bei /dev/sda mag er das lieber nicht so ohne Reboot dazwischen solange das Gerät in Gebrauch ist. Du kannst auch die bestehende Partition vergrößern und dann mit resize2fs das ext4-Dateisystem erweitern.

    Bug Report ist hier: Bug 91691 – Extremely slow disk I/O, high iowait in 3.16 and newer kernels, unless blktrace is running


    VIel herausgekommen ist dabei bis jetzt noch nicht. Wenn man blktrace laufen läßt ist die Performanz auf einmal besser. Aber das kanns ja auch nicht sein.


    Gerade habe ich mal testweise Debian Jessie-rc1 installiert. Das kommt mit einem 3.16er Kernel. Da sieht es dann so aus:


    Code
    1. # dd if=/dev/vda of=/dev/null bs=1M count=512
    2. 512+0 records in
    3. 512+0 records out
    4. 536870912 bytes (537 MB) copied, 1640.51 s, 327 kB/s


    Mir bleibt also nichts übrig, als bei einem alten Kernel zu bleiben. Anders läuft auf der Kiste nichts.


    Vor ein paar Jahren hatte ich schonmal einen Kernel-Bug, mit einem Firewire-Gehäuse das der Linux-Treiber nicht erkennen wollte. Da habe ich dem Kernelentwickler Root-Zugriff auf die Kiste gegeben und der hat das direkt am System debuggt und behoben. Das gleiche habe ich hier auch angeboten (Root-Zugang zum VServer), der Entwickler ist darauf leider nicht eingegangen. Ich weiß auch nicht mal, ob der Bisect überhaupt die richtige Stelle gefunden hat...


    felix , wenn das Problem auf Netcup-Seite reproduzierbar ist, bist du wohl in der besseren Position diesem Kernel-Bug auf die Schliche zu kommen. Ich bin hier mit meinem Latein am Ende.

    Ich habe mir Anfang Januar einen Root Server M zugelegt (das 5.49€-Angebot, Root-Server M v5a1 24M). Leider scheint das Gerät allergisch gegen Kernel neuer als 3.15 zu sein. Der Server bleibt oft stundenlang mit 100% IO-Wait hängen.


    Mir ist es relativ egal, ob ein vServer langsam ist. Ich habe keine Gameserver und auch kein Gentoo drauf, meine Ansprüche sind niedrig. Aber ich möchte doch dann und wann mal ein Systemupdate machen oder einen Tarball entpacken können ohne daß sich der Server stundenlang verabschiedet. Und ich verschenke ungerne >90% der möglichen Performanz unnötig an einen Kernel-Bug, und bei einer alten Kernel-Version bleiben ist auf lange Sicht für mich auch keine Option.


    Mein Test sieht folgendermaßen aus:


    1) Image übers Controlpanel installieren. Distribution egal (Debian, Ubuntu, Archlinux). Minimale Partitionierung. Ggf. Pakete aktualisieren.
    2) Mit parted (o.ä.) im unpartitionierten Speicher eine 512MiB große vda4-Partition erstellen (mit MiB-Alignment).
    3) 512MiB Datei im RAM erstellen und auf die Partition schreiben.

    Code
    1. truncate -s 512M /dev/shm/foobar
    2. shred -n 1 /dev/shm/foobar
    3. dd bs=1M if=/dev/shm/foobar of=/dev/vda4


    Ab Kernel 3.2.x (Rescuesystem) bis einschließlich Kernel 3.14/3.15 bekomme ich bei diesem Test 30-50MiB/s. Ab Kernel 3.16 aufwärts (einschließlich 3.19-rc4) sind es 2-3MiB/s und das System kommt dabei fast zum Stillstand. Dabei ist es egal zu welcher Tageszeit der Test durchgeführt wird, ob die Kernel selbst compiliert sind oder z.B. aus dem Ubuntu Kernel Mainline Repository stammen.


    Das sind jetzt lineare Writes und damit relativ harmlos. Aber sobald die Zugriffe zufälliger werden (z.B. ein kernel.tar.xz entpacken) kann man erstmal ins Elsaß fahren und einen Flammkuchen essen gehen. Da geht dann praktisch gar nichts mehr.


    Ein git bisect hat mich zu diesem Commit geschickt: blk-mq: split make request handler for multi and single queue · 07068d5 · torvalds/linux · GitHub


    Das muss aber nicht unbedingt stimmen da die bisect-Zwischenstände ihre ganz eigenen Krankheiten haben (Kernel Panics usw.). Und für einen einfachen git revert gibt es ein paar Konflikte. Ich komme da auch nicht wirklich weiter - bin halt weiters kein Kernel-Entwickler. Auf der LKML habe ich nur eine Problembeschreibung gefunden die meiner ähnelt - aber die dort angegebene Kernel-Version passt nicht: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1


    Bevor ich mir jetzt einen armen unschuldigen Kernel-Entwickler schnappe und diesem auf die Nerven gehe, wollte ich mal fragen, ob das Problem auch bei anderen (M v5a1) auftritt oder nicht?


    Bei meinem Root Server S ist es z.B. nicht der Fall, da läuft alles wunderbar (>50MiB/s)... lokal in einer eigenen KVM-Instanz kann ich das Problem auch nicht reproduzieren, dazu müsste man wohl im Detail wissen, wie der Netcup-Host aufgebaut ist.

    Ich steige im Moment selbst von einem Root Server S auf Root Server M um. Übertragen habe ich ganz normal mit SSH/rsync.


    Sorgen bereitet mir der hohe IO-wait. Beim entpacken eines Linux-Kernel-Tarballs bleibt die Kiste praktisch stehe.


    Überschreiben einer 512MB-Partition mit Zufallsdaten:


    Code
    1. # truncate -s 512M /dev/shm/foobar
    2. # shred -n 1 /dev/shm/foobar
    3. # dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 164.985 s, 3.3 MB/s


    Das gleiche im Rettungssystem:


    Code
    1. rescue:~# truncate -s 512M /dev/shm/foobar
    2. rescue:~# shred -n 1 /dev/shm/foobar
    3. rescue:~# dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 12.7916 s, 42.0 MB/s


    Es liegt also allem Anschein nach am Kernel. Das Rettungssystem ist 3.2.63 - das ist mir etwas zu stabil :D -, im installierten System habe ich 3.18.1 und 3.17.7 probiert.


    Auf der LKML habe ich noch jemanden mit IO-wait-Problemen bei aktuellem Kernel gefunden: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1


    Ich versuche es als nächstes mit 3.14, das läuft auf meinem Root Server S...


    Edit: Und siehe da, mit 3.14.2 und ansonsten ident. Konfiguration (make oldconfig) klappts auf einmal wunderbar:


    Code
    1. # truncate -s 512M /dev/shm/foobar
    2. # shred -n 1 /dev/shm/foobar
    3. # dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 11.8879 s, 45.2 MB/s


    Fröhliches Kernel-Bug-Hunting... ;)