Beiträge von BananaJoe

    den Artikel zu dem TRIM im ubuntuusers wiki finde ich ganz gut. Da wird auch erwähnt, dass TRIM per mountoption "discard" bei manchen SSDs probleme machen kann und man lieber fstrim nehemen sollte.
    (Der rote Kasten bei "Trim per Online-discard)
    http://wiki.ubuntuusers.de/SSD/TRIM



    Das die Uhrzeit auf UTC gestellt ist bedeutet nicht automatisch das sie per NTP bezogen wird.


    Du könntest mal prüfen ob der NTP Daemon / Service läuft.

    Code
    systemctl status <servicename>.service


    Ich kann jetzt grad nicht gucken wie der in Suse heißt, da ich es zur
    Zeit nicht installiert habe. Aber das wissen andere hier bestimmt. ;)



    Es sollten aber beide Betriebssysteme auf die gleiche Zeit (UTC bzw. localtime) eingestellt sein. Sonst kann es passieren, dass beim Wechsel zwischen den Systemen immer die Zeit verstellt wird.


    Bei den meisten Linux Distributionen wird (in der standard Konfiguration) davon ausgegangen dass die Hardwareuhr des Rechners (die Uhrzeit die man im Bios einstellt) auf UTC steht. Bei Windows7 weiss ich es nicht, da ich seit XP kein Windows mehr benutzt habe. Bei XP war es jedenfalls Localtime. Wenn man bei Win7 UTC einstellen kann würde ich persönlich das empfehlen.


    Das Problem wenn nicht beide Betriebsysteme auf die gleiche Zeit (UTC, localtime) eingestellt sind ist folgendes.


    sagen wir mal die Hardwareuhr steht auf 15:00 (UTC) die aktulle Zeit hier in Deutschland ist dann also UTC+1 Stunde (bzw. zwei wegen Sommer/Winter) also sagen wir mal 16:00


    Wenn das Betriebsystem nun auf UTC eingestellt ist und die Zeitzone auf Deutschland ist alles ok.
    Ist es aber auf Locasltime eingestellt "denkt" es die Uhr geht eine Stunde nach und (WindowsXP zumindest) verstellt die (Hardware?)Uhr auf 16:00


    Wird jetzt wieder Linux gestartet, was auf UTC steht, geht es davon aus dass die 16:00 UTC ist und rechnet noch eine Stunde (bei Zeitzone Deutschland/Berlin) drauf.


    Hoffe das war jetzt so richtig erklärt und verständlich. ;)


    Also wichtig: Beide Betriebsysteme auf die gleiche Zeit (UTC oder localtime) einstellen.

    @uhelp: Achso, dann habe ich das falsch aufgefasst.


    Ja kommt halt auf den Controller und die Firmware der jeweiligen SSD an.



    Naja und zu dem eigentlichen Thema fällt mir noch ein, wie hier schon gesagt:


    GRUB: TIMEOUT=0


    Und evtl. kernel ohne initrd? ... Und nur mit den wirklich nötigen Modulen gebaut.


    Und evtl. statische IP statt DHCP, aber ob das bei Systemd einen merklichen unterschied macht, weiss ich nicht.


    Aber ob der ganze Aufwand für ein paar Sekunden (wenn überhaupt) sich wirklich lohnt ? ....
    Da stimme ich zu. ... Aber muss ja jeder selber wissen.



    P.S.
    Bin zur Zeit etwas empfindlioch was negative Kritik angeht.
    ;)

    BananaJoe hat in soweit recht, dass, um eine gleichbleibende Schreibleistung auf SSds zu erhalten, regelmässig ein fstrim durchgeführt werden sollte (Speicherbereinigung).
    Dazu muss allerdings die SSD dieses auch unterstützen.
    Als Richtwert gilt hier wohl fstrim einmal wöchentlich auszuführen.
    Ausserdem sollte man, um Schreibzugriffe zu reduzieren, das Schreiben der letzen Zugiffszeit von Dateien und Ordnern abstellen (noatime, nodiratime).

    Danke!


    Genau darum ging es ja nur. Es wurde nach Optimierungen / Einstellungen von SSDs unter Linux gefragt, und darauf habe ich geantwortet. Nicht mehr und nicht weniger.


    Ich weiss nicht warum das hier gleich wieder so schlecht gemacht wird.


    Alex
    Damit bezwckt man, das auch nach einer gewissen Zeit, wie gesagt, die Schreibzugriffszeit gleich bleibt.


    Und das reduzieren der Schreibzugriffe mit "noatime" oder "relatime" ist sinnvoll, da Flashspeicher nur begrenzt beschrieben werden können. Ok, für die Praxis vielleicht nicht so relevant. Keine Ahnung ob sich die Lebensdauer der SSD dadurch wirklich merklich erhöht, aber schaden kann es auch nicht.


    Aber anstatt sich mal zu informieren kommt dann sowas wie:

    Code
    TRIM? Kenn ich nicht, was soll ich damit?


    @uhelp:
    Schon klar das das die Bootzeit nicht beeinflußt, aber darauf bezog sich meine Antwort ja nicht.


    Sory, aber irgendwie kommt mir das Forum hier nicht gerade sehr "freundlich" vor.
    Man Antwortet auf eine Frage und will helfen und dann wird die Antwort, obwohl sinnvoll, gleich wieder so niedergemacht.

    Für SSD notwendige Optimierungen habe ich mit der Hilfs-Software und Tips aus PC-Zeitschriften unter Windows durchgeführt. Ist hier bei Suse 12.2 noch etwas zu tun?

    TRIM sollte noch eingerichtet werden, fall noch nicht geschehen. ;)


    Entweder (falls das Dateisystem ext4 ist) in der /etc/fstab die mountoption "discard" hinzufügen,
    oder ab und zu manuell fstrim ausführen. Das kann man z.B. mit einem täglichen Cronjob erledigen.


    Und evtl noch eine der mountoptionen "noatime" oder "relatime", die reduzieren die Schreibzugriffe.

    ich habe den Fehler nun hoffentlich gefunden.


    scheint wohl ein Problem mit der Firmware der SSD zu sein. Ab 5184 "Power on Hours" tritt mit alten Firmware Versionen wohl genau der Fehler auf. (bei meiner waren es 5183 laut SMART)


    http://forum.crucial.com/t5/So…t-random/m-p/84668#M25639


    Ich habe jetzt erfolgreich ein Firmwareupdate auf die neuste Version gemacht und hoffe das Problem ist damit behoben.


    P.S.
    Blöd das die Kommunikation in diesem Thread so blöd gelaufen ist. 8|

    ok, hier noch mal die ausgaben zu den Festplatten, nur falls es doch nicht das Problem war.


    gdisk /dev/sda


    fdisk -l


    /etc/fstab


    cron.daily

    Code
    cat /etc/cron.daily/trim 
    
    
    
    
    #!/bin/bash
    
    
    /sbin/fstrim /

    Es sind zwei Platten drin sda ist eine SSD mit der Rootpartition und einer Swap. SMART Ausgabe ist auch ok.


    mir ist aber gerade aufgefallen, dass die Rootpartition den falschen Partitionstyp hat.


    Da bin ich nicht drauf gekommen. Ich vor der Installation von Suse von einer LiveCD aus mit gptfdsik eine GPT PArtion (wegen dem alignement)erstellt, da ich mir nicht sicher war ob der Installer GPT Partitionen anlegt. Bei der Installation habe ich im Installer dann die Partition nur formatieren lassen.


    Entweder ich hatte beim erstellen den Fehler gemacht, oder der Installer hat das geändert.


    Ich hoffe das war der Fehler.


    P.S.
    Und wenn ich nochmal anmerken darf, der Ton den Du hier an den Tag legst ist schon etwas beleidigend.
    Auch wenn ich vielleicht nicht sofort alle Informationen geliefert habe und es schwierig ist dann eine Lösung zu finden, .... dumm bin ich nicht!


    sorry normalerweise schreib ich sowas ja nicht, aber das musste jetzt mal raus.

    hm, die Festplatte ist erst ca. ein Jahr alt. Ok dass muss nichts heissen ...
    Aber bei den SMART Werten kann ich, soweit ich die Ausgaben verstehe nichts auffälliges finden.
    Oder irre ich mich da? ... aber könnte ja trotzdem ein Problem geben mit der Festplatte.
    Naja, auffällige Geräusche macht sie zumindest nicht.


    http://pastebin.com/BgsNVkDH



    Mir ist schon klar das Neuinstallieren/Wechsel eigentliche keine Lösung ist.
    Hatte bis jetzt sei etwa 6 Jahren Arch Linux und habe es in der ganzen Zeit nur einmal neuinstalliert.
    Wegen Rechnerwechsel von i686 auf x86_64. Wollt ich nur mal anmerken. ;)


    EDIT:
    Evtl. liegt es aber auch an dem prop. NVIDIA Treiber, ich habe jetzt mal den nouveau Treiber installiert und seit dem ist es bis jetzt nicht mehr passiert.


    EDIT:
    Und ich vermute mal das die Dateisystemfehler so viele waren, da mir bei den Hängern nichts anderes übrig blieb als den Rechner jedesmal einfach per Powerknopf ausschalten musste ...