Danke, aber ich weiss schon wie man das macht. ![]()
Mir war nur danach das für den Fragesteller nochmal etwas zu erklären, weil ich den Eindruck hatte da herrscht noch viel Unklarheit.
Danke, aber ich weiss schon wie man das macht. ![]()
Mir war nur danach das für den Fragesteller nochmal etwas zu erklären, weil ich den Eindruck hatte da herrscht noch viel Unklarheit.
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.
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.
halte ich für keine wirklich gute Idee. Ich würde das wenigstens auf 2 Sekunden einstellen. Das erleichtert Einiges, falls es mal Probleme gibt und man manuell im Bootloader eingreifen muss.
Ja das stimmt natürlich. Aber ich dachte halt: wenn schon denn schon ![]()
Und im Notfall kann man ja immer noch eine LiveCD benutzten ...
@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:
@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. ![]()
ok, hier noch mal die ausgaben zu den Festplatten, nur falls es doch nicht das Problem war.
gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7700BDC2-0065-4EDF-B3CD-384D0A8E2E4F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 108267519 51.6 GiB 8300 Linux filesystem
2 108267520 125044735 8.0 GiB 8200
Alles anzeigen
fdisk -l
Warnung: GPT (GUID-Partitionstabelle) auf '/dev/sda' erkannt! Das Hilfsprogramm Fdisk unterstützt GPT nicht. Verwenden Sie GNU Parted.
Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 Köpfe, 63 Sektoren/Spur, 7783 Zylinder, zusammen 125045424 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x03450344
Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 1 125045423 62522711+ ee GPT
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 Köpfe, 63 Sektoren/Spur, 60801 Zylinder, zusammen 976773168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x0001b1bb
Gerät boot. Anfang Ende Blöcke Id System
/dev/sdb1 2048 853708799 426853376 83 Linux
/dev/sdb2 * 853710165 976773167 61531501+ 7 HPFS/NTFS/exFAT
Alles anzeigen
/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=8bcc45c9-67d4-42a5-add3-0dfc23e2faea / ext4 noatime,errors=remount-ro 0 1
# /home was on /dev/sdb1 during installation
UUID=669489ad-b8b9-4cdd-a092-70a227583f43 /home ext4 defaults 0 2
UUID=9fddafbe-4cd7-4f37-90b9-910ec3945cf9 none swap sw 0 0
tmpfs /tmp tmpfs nosuid 0 0
Alles anzeigen
cron.daily
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.
gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7700BDC2-0065-4EDF-B3CD-384D0A8E2E4F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 108267519 51.6 GiB EF00 Linux filesystem
2 108267520 125044735 8.0 GiB 8200
Alles anzeigen
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.
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 ...