Installation auf SSD - Was ist zu beachten?

[Tripp]

Hallo,

ich installiere jessie heute (zum ersten mal) auf eine ssd (samsung 840 evo). Gibt es hier irgendwas das ich beachten muss? Ich habe nämlich bei meiner vorabrecherche einige male von fstab paramtern wie "realtime" und "discrad" gelesen, bin aber trotzdem noch unsicher. Muss ich die in die fstab eintragen oder wird das beim installieren automatisch, beim erkennen das eine ssd verbaut ist, eingetragen?

Kann das vorhanden- oder nicht vorhandensein dieser paramter auswirkungen auf die lebensdauer meiner ssd, sprich kaputt wenn nicht eingetragen, haben?

Danke!

[owl102]

Muss ich die in die fstab eintragen oder wird das beim installieren automatisch, beim erkennen das eine ssd verbaut ist, eingetragen?

Es gibt keine SSD-Erkennung, also letzteres.

Kann das vorhanden- oder nicht vorhandensein dieser paramter auswirkungen auf die lebensdauer meiner ssd, sprich kaputt wenn nicht eingetragen, haben?

Ja, deswegen setzt man sie ja

Hier eine kurze Zusammenfassung, mit absteigender Wichtigkeit:

1. Auf das Alignment der Partitionen achten, moderne Tools partitionieren auf 1MB-Grenzen, damit ist man auf der sicheren Seite. Warum: Lese/Schreibgeschwindigkeit + Lebensdauer. Test: "fdisk -lu /dev/sda" (oder klicki-bunti mit GParted), "Start" sollte für alle Partitionen durch 2048 teilbar sein
2. Entweder die Option "discard" für alle Partitionen auf der SSD in die /etc/fstab packen, oder aber hin-und-wieder fstrim manuell aufrufen. Welche Methode die bessere ist, da scheiden sich die Geister, es wird auch IMHO viel FUD um "discard" betrieben, ich habe damit seit Jahren keinerlei Probleme, bei 5 SSDs (Intel/Samsung/SanDisk). Warum: Schreibgeschwindigkeit + Lebensdauer
3. /tmp in eine RAM-Disk packen, sofern genügend RAM im Rechner steckt. Warum: Lebensdauer
4. Die Option "noatime" für alle Paritionen auf der SSD in die /etc/fstab packen. Warum: Lebensdauer. Achtung: Manche Programme verlassen sich auf einen gültigen "atime"-Zeitstempel, die fallen dann auf die Nase

[Tripp]

Danke für den hinweis, ich werde die punkte beherzigen.

1. /tmp in eine RAM-Disk packen, sofern genügend RAM im Rechner steckt. Warum: Lebensdauer

D.h. nach der installation sollte ich das /tmp verzeichnis in den ram verlagern. Laut meiner recherche wird hierfür, wenn nichts angegeben wird, maximal die hälfte des rams verwendet. Reicht das, oder würdes du aus eigener erfahrung sagen, das mehr notwendig wäre? Mir stehen 8 GB ram zur verfügung.

[owl102]

Reicht das, oder würdes du aus eigener erfahrung sagen, das mehr notwendig wäre?

Selbst bei meinem Rechner mit 3GB RAM reicht das. Größere Mengen sollten auch nicht in /tmp, sondern in /var/tmp landen. (Was natürlich nicht heißt, daß sich alle Anwendungen daran halten, bisher ist mir aber noch kein Bösewicht untergekommen.)

[Tripp]

Ok, dann reicht die default einstellung.

Ich hab mir gerade den FHS angesehen, und vermutlich ist es eine gute idee, /var auf einer HDD zu erstellen.

[joahlen]

[...]
[*] Die Option "noatime" für alle Paritionen auf der SSD in die /etc/fstab packen. Warum: Lebensdauer. Achtung: Manche Programme verlassen sich auf einen gültigen "atime"-Zeitstempel, die fallen dann auf die Nase

Hast Du Beispiele?

JO

[catdog2]

Die Option "noatime" für alle Paritionen auf der SSD in die /etc/fstab packen. Warum: Lebensdauer. Achtung: Manche Programme verlassen sich auf einen gültigen "atime"-Zeitstempel, die fallen dann auf die Nase

Dafür gibts dann "relatime" als Kompromiss.

Hast Du Beispiele?

Wenn ich mich richtig erinnere mutt (verwende ich aber nicht deswegen bin ich mir nicht sicher) sind aber wohl eher wenige, die da Probleme machen.

Zu der Lebensdauer Geschichte: blos nicht übertreiben mit dem vermeiden von Schreibzugriffen, auf moderen SSDs (zumindest bei den guten) kann schon ordentlich drauf rumschreiben ohne dass die gleich kaputt gehen.

[MrGerardCruiz]

Irgendwie erinnert mich das Thema an die ewigen Akku-Diskussionen. Die haben manche wie rohe Eier behandelt, mit dem Ergebnis, dass man nach Expertenrat die Teile am Besten gar nicht mehr benutzt hat. Hardware ist letztlich Verschleißgegenstand, das sollte man immer im Hinterkopf behalten. Was nützt mir eine Festplatte, die man nicht beschrieben darf?

[Patsche]

Naja, aber bei SSD's ist es schon richtig, dass man sich um die richtige Mountoption kümmert und ein riesen Aufwand ist es ja auch nicht. Ich würde auch kein Akku mit 10A Ladestrom aufladen

[smutbert]

Diese Diskussion hatten wir zwar schon einmal, aber ich muss zur ersten Antwort von Owl102 trotzdem nachhaken

Soweit ich weiß ist der einzige Unterschied zwischen /tmp und /var/tmp, dass man bei letzterem davon ausgehen darf, dass der Inhalt nach einem Neustart noch vorhanden ist, während ersteres Verzeichnis beim Systemstart üblicherweise gelöscht wird. Mit der Größe hat der temporären Dateien hat das nichts zu tun.
Es ist meiner Meinung nach auch durchaus sinnvoll, dass ein Platz existiert, an dem Programme temporäre Dateien auf einem Massenspeichermedium anlegen können. Ginge es nämlich um kleine Dateien, die vielleicht im Hauptspeicher besser aufgehoben wären, könnte man sie gleich in einem tmpfs im Hauptspeicher ablegen oder sie im Hauptspeicher belassen ohne eine Datei daraus zu machen.
Für viele Zwecke gibt es außerdem bereits einige Orte, an denen ein tmpfs eingebunden ist - hier auf meinem System zB:

Code: Alles auswählen

$ mount | grep tmpfs
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1920789,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=3076480k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
tmpfs on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)

(Das ist ein Debian mit systemd, mit einem anderen init-System würden vielleicht 1 oder 2 davon wegfallen)

[…] fstab paramtern wie "realtime" und "discrad" gelesen, bin aber trotzdem noch unsicher. […]

Die Parameter heißen relatime und discard. relatime ist glaube ich überflüssig, weil es inzwischen der default ist, noatime dagegen ist durchaus überlegenswert (ich hab's in der fstab drin). Ich habe bis jetzt kein Programm gefunden, das sich an den fehlenden/falschen Access Times stört.
discard aktiviert das laufende freigeben von freigewordenen Speicherbereichen (online discard). Ich habe es nicht in der fstab drin und rufe stattdessen gelegentlich manuell fstrim auf (batched discard), also wenn man für / und /home je eine eigene Partition angelegt hat, zB

Code: Alles auswählen

fstrim -v /
fstrim -v /home

Ob man das im laufenden Betrieb erledigt haben will oder manuell machen will ist geschmackssache.
Manche Parameter opimieren verschieden Dateisysteme übrigens schon, wenn sie merken, dass sie auf einer SSD liegen. swap zB macht ganz automatisch das "online discard" und auch btrfs ändert das Verhalten etwas, wenn es auf einer SSD liegt (es versucht möglichst große zusammenhängende freie Speicherbereiche zu beschreiben).

[…]
Ich hab mir gerade den FHS angesehen, und vermutlich ist es eine gute idee, /var auf einer HDD zu erstellen.

Das hielte ich für deutlich übertrieben. Die üblichen SSDs werden vermutlich sowieso in so gut wie allen Fällen sehr viel länger leben, als die Computer in denen sie drinnen stecken. Und man profitiert nicht von den schnelleren Schreibzugriffen, wenn man alle Daten, die etwas öfter geschrieben werden auf eine HDD legt. apt und dpkg arbeiten auf einer SSD zB merklich schneller, was ich als sehr angenehm empfinde. (Ich habe alles auf einer SSD).


Im Endeffekt ist das einzige, was ich außer noatime und "batched discard" (oder wahlweise "online discard") machen würde, die "Reserve" (HPA - host protected area) der SSD etwas zu vergrößern.
Das verringert die verfügbare Kapazität der SSD, aber dafür ist, auch wenn das Dateisystem voll ist oder man vergessen hat trim auszuführen, noch genug freier Speicher auf der SSD, der der Performance von Schreibzugriffen gut tut und der SSD bestimmt auch das Wear Leveling erleichtert. Die HPA läßt sich mit

Code: Alles auswählen

hdparm -Npxxx /dev/sdy

vergrößern, wobei p für permanent und xxx für die Zahl der hinterher noch zugänglichen Sektoren steht, /dev/sdy ist naturlich durch die passende Gerätedatei zu ersetzen. Der Befehl läßt sich übrigens pro Kaltstart nur einmal ausführen - ich empfehle dazu die Lektüre der Manpage von hdparm.

Den gleichen Effekt hat es, wenn man einfach einen Teil der SSD unpartitioniert läßt (ist vielleicht etwas simpler).

[dirk11]

Naja, aber bei SSD's ist es schon richtig, dass man sich um die richtige Mountoption kümmert

Wobei das einzig wirklich wichtige das Alignment ist. Die Mount-Option "discard" wird. z.B. für verschlüsselte Partitionen explizit nicht empfohlen.

und ein riesen Aufwand ist es ja auch nicht. Ich würde auch kein Akku mit 10A Ladestrom aufladen

Tja, wenn man keine Ahnung hat... Die NiCd, die bei mir am längsten überlebten, wurden immer mit >7A geladen.

[Radfahrer]

Ich würde auch kein Akku mit 10A Ladestrom aufladen

Ist im Modellbau absolut normal. Entladen werden sie dann in einem schnellen Elektroflieger mit bis zu 100 Ampere Strom und mehr.

Was die Lebensdauer von SSDs angeht: Die ist mittlerweile höher als bei mechanischen HDDs. Und selbst meine alte OCZ Vertex 2 die seit November 2010 im Einsatz ist, hat noch nichts von ihrer Performance eingebüßt. Und da ist das komplette System drauf.
Wenn man ausgerechnet die Dinge mit hoher Schreib/Lesedichte von der SSD ausnimmt, hätte man sich ja auch keine zulegen brauchen, denn genau da macht sich die Geschwindigkeit am meisten bemerkbar. Für Daten, die alle Jubeljahre mal verändert werden, braucht man keine SSD.

Jedenfalls sind die Zeiten, in denen eine SSD besonders empfindlich war, vorbei. Die kann man benutzen, wie jede andere Festplatte auch.

[Patsche]

Tja, wenn man keine Ahnung hat... Die NiCd, die bei mir am längsten überlebten, wurden immer mit >7A geladen.

Scheint deine persönlich Empfindung zu sein, aber ich habe einige Zeit in einer Akkuwerkstatt gearbeitet, wo ich selbser Akku's für die Bundeswehr gefertigt und formatiert haben. Natürlich kommt der Ladestrom auf die Kapazität an, aber einen 2000mAh Akku würde ich niemals mit 7A laden, also brauchst du nicht mit keine Ahnung kommen. Akku's sollte man vornehmlich mit 1/10 der Kapazität pro Stunde laden. Beim Militär wird sogar mit 1/5 geladen. Sprich bei bei 1/10 und 2000mAh sollte man am besten mit 200mAh laden um den Akku zu schonen. Ich könnte jetzt Beispiele geben, aber ich denke du kannst Gugle bedienen Des Weiteren sind diese Akku's seit 2004 EU-weit verboten worden. Hast du noch Restbestände ^^ Außerdem ist der Thread dafür falsch

Edit:
Hohe Ladeströme dienen nur dazu, weil wir nicht lange warten wollen in der schnellen Welt.

[dirk11]

Scheint deine persönlich Empfindung zu sein,

Wenn Du "Empfindung" mit Erfahrung austauschst, liegst du mit deiner Vermutung schon näher.

Natürlich kommt der Ladestrom auf die Kapazität an, aber einen 2000mAh Akku würde ich niemals mit 7A laden, also brauchst du nicht mit keine Ahnung kommen.

Doch, da komme ich dir aber mit keine Ahnung. Für einen Akku ist es vollkommen egal, ob es sich um einen Lade- oder um einen Entladestrom handelt. Und ein Akku z.B. in einem Akkuschrauber wird mit Strömen von bis zu 100A beaufschlagt - also lädt man ihn auch mit hohem Strom.

Akku's sollte man vornehmlich mit 1/10 der Kapazität pro Stunde laden.

Das ist so pauschal schonmal vollkommen falsch und im speziellen Wissen von vor 30 Jahren, welches schon lange nicht mehr stimmt.

Beim Militär

... wird vermutlich auch noch an 486ern gearbeitet.

um den Akku zu schonen.

Ein Akku muss nicht "geschont" werden, das wird er im Einsatz auch nicht.

Außerdem ist der Thread dafür falsch

Nja, du meinst ja, veraltetes Wissen verbreiten zu müssen.

Hohe Ladeströme dienen nur dazu, weil wir nicht lange warten wollen in der schnellen Welt.

Schon wieder falsch.
Du solltest deine BW-Erkenntnisse mal auffrischen. Es ist ein Unterschied, ob man - wie bei der Bundeswehr - Fahrzeuge "pflegt", in dem man das unten abgelassene Öl oben wieder einkippt, weil der Motor damit erst 10km gefahren hat und man nur die Intervalle einhalten muss, oder man die Gerätschaften auch benutzt. Dasselbe gilt für die Akkus beim BUND.

[dufty2]

Die Platte von Anfang an verschlüsseln.
Wer weiß, ob man am Ende wieder alles gelöscht bekommt ...

[DeletedUserReAsG]

OT:

Akku's sollte man vornehmlich mit 1/10 der Kapazität pro Stunde laden. Beim Militär wird sogar mit 1/5 geladen. Sprich bei bei 1/10 und 2000mAh sollte man am besten mit 200mAh laden um den Akku zu schonen.

Hängt dann doch sehr vom Akku selbst ab. Li-Akkus sind standardmäßig bei 0.5C zu laden, was bei ’nem durchschnittlichen 18650er zu 1-1.5A Ladestrom (während der CC-Phase) führt. Davon abgesehen gibt es im normalen Handel bis 2C spezifizierte, woraus sich 4-6A Ladestrom ergeben. Darüber hinaus gibt es Hochstromzellen, die noch einige Größenordnungen darüber liegen.

On Topic: bei denen von den Herstellern heutzutage angegebenen Daten müsste man sich nicht mal um atime/noatime, /tmp, /var/log und so weiter kümmern. Ich probier’s gerade mal aus, bin aber mit der 840 erst im zweiten Jahr. Einen abschließenden Bericht gibt es dann in acht Jahren, oder wenn das SSD aufgibt – je nachdem, was zuerst eintritt.

[joahlen]

Die Platte von Anfang an verschlüsseln.
Wer weiß, ob man am Ende wieder alles gelöscht bekommt ...

Die Axt im Haus ersetzt....

Zum Thema:
Ich arbeite seit drei oder vier Jahren auf mehr oder weniger allen Rechnern ausschließlich mit kleinen (16 und 32 GB) SSD als Systemlaufwrk (/) mit /swap, und einer Datenpartition auf einer HDD.

Nach anfänglicher Scheu und viel Gefrickel nach allen möglichen Tipps und Tricks hab ich mir nun angewöhnt einfach zu installieren und gut ist. Außer noaltime in der fstab mache ich schlicht gar nichts.

Und meine - meist gebraucht gekauften - SSD funktionieren alle noch und zeigen auch bei diversen Testprogrammen keine Abnutzungserscheinungen. Auch die zwei Bastellaufwerke nicht, auf denen ständig irgendwas neu installiert, formatiert und partitioniert wird.
Und wenn doch wäre das bei den Preisen heute leicht zu verschmerzen.

Also, NO PANIC und die Antwort ist 42. Aber das wusstet ihr ja schon.


JO

[Dogge]

Naja, aber bei SSD's ist es schon richtig, dass man sich um die richtige Mountoption kümmert

Wobei das einzig wirklich wichtige das Alignment ist. Die Mount-Option "discard" wird. z.B. für verschlüsselte Partitionen explizit nicht empfohlen.

Hast du eine Quelle dafür?
Ich habe bisher immer nur folgendes gehört: "SSD → discard". Folglich habe ich es bei meinem Netbook mit SSD auch aktiviert. Aber ein Netbook, das ich ja unterwegs dabei haben möchte wird natürlich verschlüsselt.

[catdog2]

Hast du eine Quelle dafür?
Ich habe bisher immer nur folgendes gehört: "SSD → discard". Folglich habe ich es bei meinem Netbook mit SSD auch aktiviert. Aber ein Netbook, das ich ja unterwegs dabei haben möchte wird natürlich verschlüsselt.

http://asalor.blogspot.de/2011/08/trim- ... blems.html

[smutbert]

Naja, aber bei SSD's ist es schon richtig, dass man sich um die richtige Mountoption kümmert

[…]Die Mount-Option "discard" wird. z.B. für verschlüsselte Partitionen explizit nicht empfohlen.

Hast du eine Quelle dafür?
Ich habe bisher immer nur folgendes gehört: "SSD → discard".[…]

Ist da wirklich eine Quelle notwendig? Es geht schlicht um einen Interessenkonflikt:

Verschlüsselte Daten lassen sich, solange man nicht im Besitze des Schlüssels ist, nicht von zufälligen Daten unterscheiden. Für einen Angriff auf die Verschlüsselung ist es naheliegenderweise sehr von Vorteil zu wissen wo überhaupt verschlüsselte Daten sind und was nur Datenmüll ist und genau das kann man, denn wenn discard aktiviert ist, dann liefern freie Speicherbereiche nur mehr Nullen.
Wenn es also nach der SSD geht, aktiviert man discard bzw. führt regelmäßig trim aus, wenn es dagegen um ein Maximum an Sicherheit geht, läßt man das mit trim/discard bleiben und achtet darauf, dass vor Anlegen der verschlüsselten Dateisysteme, alles mit zufälligen Daten überschrieben wurde - in dem Fall würde ich aber auf jeden Fall die HPA, die ich in meinem vorigen Post erwähnt habe, etwas großzügiger auslegen, denn genügend als frei bekannte Speicherbereiche sind für jeden Schreibzugriff von Vorteil.

[dirk11]

Zumal man bei den heutigen Systemen den vermeintlichen Vorteil von trim sicherlich sowieso nicht bemerkt, denn dafür gibt es overprovisioning, sprich die SSD hat ab Werk immer free-space im Hintergrund.

[dufty2]

Die Platte von Anfang an verschlüsseln.
Wer weiß, ob man am Ende wieder alles gelöscht bekommt ...

Die Axt im Haus ersetzt....

Zum Thema:

Meine Anspielung bezog sich auf "wear-leveling & Co.", welche dazu führen könnten, dass nicht-verschlüsselte Sektoren von der SSD-firmware "wegkopiert" werden, dass selbst ein "dd of=/dev/sda ..." - sprich mit Betriebssystem-mitteln - sie nicht mehr erreichbar/löschbar sind.

[DeletedUserReAsG]

Wenn es von Anfang an verschlüsselt ist, bekommt das Wear-Leveling-Zeugs des SSD doch nie einen unverschlüsselten Block zu Gesicht?

[dufty2]

Wenn es von Anfang an verschlüsselt ist, bekommt das Wear-Leveling-Zeugs des SSD doch nie einen unverschlüsselten Block zu Gesicht?

Eben, und was schrieb ich als Tipp?

Die Platte von Anfang an verschlüsseln.

[DeletedUserReAsG]

Kontextfehler meinerseits, entschuldige.