Beiträge von letsfindaway

    Du weißt schon, dass du dir damit in beiden Fällen die Ausfallwahrscheinlichkeit erhöhst? Wenn nur eine der beiden Platten ausfällt, sind alle Daten futsch. Hättest du die beiden Platten getrennt gemountet, dann würde ein Ausfall nur die Hälfte betreffen.


    Wenn du dir dessen bewusst bist und ein gutes Backup hast, dann würde ich gefühlsmäßig LVM nehmen. Das ist flexibler und würde es z.B. auch gestatten, noch eine dritte Platte hinzuzunehmen, egal welcher Größe. RAID-0 könnte allerdings Performance-Vorteile bieten. Die Performance halte ich aber bei deinen beiden SSDs für ausreichend. Zumindest kann ich mir nicht vorstellen, wo das noch ein gewichtiges Argument sein könnte.


    Aber vielleicht solltest du deine Frage ergänzen um Punkte, die dir an einem Plattenverbund besonders wichtig sind. Für meine Zwecke wären z.B. 2 TB sowas von ausreichend, dass ich eher über ein RAID-1 nachdenken würde, um die Ausfallsicherheit zu erhöhen.

    Nee, das reicht nicht. Und ich denke, im Post hast du noch einen Fehler: im Text redest du von 192.168.0.x, in den Ausgaben erscheint aber 192.168.100.x. Außerdem vermute ich, dass die 192.168.100.254 nicht direkt mit dem Internet verbunden ist, sondern dass das ein NAT Router ist. Aber unabhängig davon: das IP Forwarding und deine Route sind nicht ausreichend. Was passiert beim Traceroute an deinem "Zweitrechner":

    • Ein IP Paket wird erzeugt. Source IP 192.168.2.20, Destination IP 193.99.144.80
    • Auf Grund der Default Route wird dieses Paket an 192.168.2.1 weitergereicht, also zum Server. Das geschieht, indem die MAC Adresse von 192.168.2.1 ermittelt wird und diese als Ethernet Destination in das Paket geschrieben wird.
    • Dort wird es auf Grund des eingeschalteten IP Forwardings erneut analysiert, die Routing Tabelle wird konsultiert
    • Diese hat wieder eine Default Route nach 192.168.100.254, also geht das Paket über das 192.168.100.20er Interface in diese Richtung raus, ebenfalls wieder über MAC Adress Lookup.
    • Das ist nun dein NAT Router. Der ersetzt die Source IP durch seine eigene öffentliche Internet-IP und schickt das Paket ins Internet. Er merkt sich dabei, wie die Source IP denn war.
    • Das Paket get vermutlich erfolgreich durch alle Internet-Router zum Ziel, und die Antwort geht auch wieder zu deinem NAT Router. Bis hierher alles paletti!
    • Der ersetzt die Zieladresse nun wieder durch die ursprüngliche Source Adresse, also die 192.168.2.20
    • Jetzt macht dein NAT Router ein MAC Lookup (ARP Request), um die MAC Adresse zu bestimmen, die zu 192.168.2.20 gehört. Aber leider gibt es auf diesem Netzwerk niemand mit dieser Adresse, also antwortet keiner auf den ARP Request.
    • Das Paket wird verworfen.

    Wenn du so ein Setup machen willst, dann funktioniert das nur vernünftig, wenn du an deinem Server auch ein NAT einrichtest. Dann werden alle Adressen korrekt übersetzt. Wie das geht, soll dir aber jemand anderes erklären.

    Das hat mich jetzt auch überrascht und deshalb hab ich mal nachgeforscht. Es sieht so aus, als ob die Funktion fmax in math.hnicht definiert wird, wenn -ansi angegeben ist. Das kann man erkennen, wenn man den Compiler mal mit der Option -E -o fmax_test.preprocessed.c aufruft und das Ergebnis nach dem Preprocessor anschaut: keine Spur einer Definition von fmax.


    ANSI C nimmt in einem solchen Fall an, dass die fmax als int fmax(int,int) definiert ist, und das ergibt den von dir gezeigten Effekt.Ich hab dein Programm nun mal mit der Deklaration double fmax(double,double); vor der main ergänzt, und schon geht alles wie erwartet.


    Hier hatte jemand schon vor Jahren diese Frage: https://stackoverflow.com/ques…laration-of-function-fmax

    Und die Antwort ist auch hier, dass fmax mindestens C99 erfordert, um in math.h deklariert zu werden.


    Das scheint auch korrekt zu sein. Zumindest führt https://de.wikipedia.org/wiki/Math.h die Funktion fmax nicht in der Liste der bis C95 definierten Funktionen auf,

    Danke!


    Ja, das hatte ich in der Tat auch gemacht. Das Ergebnis war, dass display-manager-service die eine Minute gebraucht hat. Das deckt sich etwa mit dem Journal. Ein systemctl status display-manager.service hat aber keine Auffälligkeiten gezeigt: der Service war gestartet, da sah alles normal aus. Diesmal hat er schnell gebootet, deshalb kann ich die Ausgabe momentan nicht zeigen. Ich habe ja in der Überschrift geschrieben, dass das sporadisch auftritt: etwa 1 von 10 Boot-Vorgängen dauert so lange.

    Hallo zusammen,


    inzwischen hab ich meine Rechner erfolgreich auf Leap 15.2 aktualisiert. Dabei ist auch ein Desktop, de seither beim Booten sehr lange braucht - mehr als 1 Minute. Der Log zeigt mir dann folgende Meldungen (Ausschnitt):

    Um 16:43:39 wird versucht, die Keymap zu setzen. um 16:44:08 gibt es dann einen Timeout, hat nicht funktioniert. Ein weiterer Timeout läuft dann um 16:44:34 ab.


    Danach startet die KDE Oberfläche. Allerdings mit einigen Problemen. So findet z.B. die Lautstärkeregelung keine Geräte, aber ich halte das erst mal für einen Folgefehler.


    Im Gutfall sind die oben gezeigten Timeout-Meldungen nicht vorhanden und der oben gezeigte Ausschnitt läuft in unter 1 Sekunde durch.


    Das Problem habe ich erst seit dem Update auf Leap 15.2. Hat da jemand eine Idee, woran das liegen könnte? Wo könnte ich noch nach weiteren Indizien suchen?

    Die aktualisierten und fehlerbereinigten Pakete kommen mit Leap 15.2, also Ende des Monats. Der Fehler ist schon länger bekannt, ein Backport der Korrektur nach 15.1 wurde aber nicht ausgeführt.


    Ansonsten würdest du die aktualisierten Pakete für 15.1 auch in meinem Repository finden: https://download.opensuse.org/…daway/openSUSE_Leap_15.1/


    Wegen Abhängigkeiten muss neben cups-filters auch qpdf aktualisiert werden.


    Siehe auch https://bugzilla.opensuse.org/show_bug.cgi?id=1131863

    Ich würde mich da nicht nach der Versionierungsnummer richten. Neuer ist immer die Version mit dem neueren Zeitstempel.

    Echt? Dann baue ich dir morgen irgendein Paket aus gaaanz alten Sourcen. Das ist dann neuer, oder? Nee, die Frage ist , was "aktueller" ist. Und die hat der Thread noch nicht zufriedenstellend beantwortet.

    Eine solche Hardware- DCF Uhr kannst du für lau kaufen und an deine Kiste hängen.

    Nun ja, DCF77 kennt verschiedene Modi:


    Den einfachen verwendet jeder Radiowecker. Da gibt es Sekundenpulse, nach denen man sich einfach richten kann. Das ist für lau.


    Die für einen Stratum 1 NTP Server verwendeten Empfänger, meist von Meinberg, nutzen noch ganz andere Features des Funksignals. Aus der Webseite des RRZE:


    Zitat von RRZE

    Als Zeitquelle dienen dabei entweder Navigations-Satellitensysteme wie das GPS, die bedingt durch ihre Funktionsweise quasi als Abfallprodukt nebenbei ein extrem genaues Zeitsignal ausstrahlen, oder das Funksignal des offiziellen deutschen Zeitsenders „DCF77“. Letzteres ist prinzipiell das gleiche Signal, wie es auch handelsübliche Funkuhren für den Hausgebrauch verwenden. Anders als diese decodieren die hier verwendeten Empfänger jedoch auch die zusätzlich auf dieses Signal aufmodulierten Pseudozufallsfolgen (PZF), die eine extrem genaue Zeitsynchronisation erst möglich machen – anderenfalls läge die erzielbare Genauigkeit „nur“ im Bereich von etwa 10 Millisekunden statt weniger Mikrosekunden.

    Diese Empfänger kosten einige Tausender. Für meinen Geldbeutel ist das dann nicht mehr so lau. Da misst man dann beim Einrichten auch die Entfernung zum Sender genau aus, um die Signallaufzeit rausrechnen zu können. Selbst die rechterinternen Laufzeiten vom Hardware-Eingangssignal durch den Kernel bis zur Systemuhr werden bei solch genauen Aufbauten mit eingerechnet.

    Hier Infos zu den Zeitservern der Uni Erlangen:


    zeitserver


    Die dort verwendeten Hardwareuhren basieren auf GPS oder DCF77 und erreichen Genauigkeiten von wenigen Mikrosekunden. DCF77 wird direkt von der PTB gespeist, GPS bezieht seine Uhrzeit aus weltweit verteilen Atomuhren.


    Ob du dich nun direkt mit der PTB verbindest oder mit einem Stratum 1 Server, der die Zeit aus den genannten Quellen bezieht, ist für dich wirklich irrelevant. Die ntp-Genauigkeit ist im besten Fall bei 0,2 ms (siehe Network Time Protocol – Wikipedia). Die Uhren laufen auf Mikrosekunden genau.



    Also für dich ist das echt Jacke wie Hose.