Einbindung einer 256GB-SSD in mein Desktopsystem

30/04/2016 - 14:00 von Peter Schütt | Report spam
Hallo,
ich, Debian/Testing, habe mir eine SSD mit 256GB gegönnt und möchte sie
jetzt in meinem Destop-Rechner einbinden.

Meine Überlegung ist:

Die Programmzweige /bin /usr /opt /lib sollen auf die SSD wandern, weil da
ja nur wenig geschrieben, aber viel gelesen wird.

Der Rest bleibt auf der normalen Festplatte (/var /home).

1. Was haltet Ihr davon?
2. Wie gehe ich da am Besten vor?

So sieht meine (verkürzte) df-Ausgabe aus:

Dateisystem Größe Benutzt Verf. Verw% Eingehàngt auf
tmpfs 799M 1,6M 798M 1% /run
/dev/sda2 66G 30G 33G 48% /
tmpfs 4,0G 64K 4,0G 1% /tmp
/dev/sda1 49G 47G 2,6G 95% /win_c
/dev/sda6 30G 17G 12G 58% /var
/dev/sda7 11G 333M 10G 4% /var/tmp
/dev/sda8 747G 692G 18G 98% /home


(Die eigene Partition für /var/tmp hat historische Gründe.)

Ideal wàre es wahrscheinlich, die /dev/sda2 vollstàndig auf die SSD zu
migrieren. Aber wie geht das?
Und was könnte man da sonst noch draufpacken?

Oder ist ein hàufiges Beschreiben auf SSD's heutzutage unkritisch, so dass
man auch eine SWAP-Datei, Windows-VM-Container und sonstiges auf VAR auf die
SSD schieben könnte?

Ciao
Peter Schütt


www.pstt.de
 

Lesen sie die antworten

#1 Sven Hartge
30/04/2016 - 16:10 | Warnen spam
Peter Schütt wrote:

Oder ist ein hàufiges Beschreiben auf SSD's heutzutage unkritisch, so
dass man auch eine SWAP-Datei, Windows-VM-Container und sonstiges auf
VAR auf die SSD schieben könnte?



Die Meinung, dass SSDs schon durch geringe Schreibmengen "sofort" kaputt
gehen und daher wie rohe Eier zu behandeln sind, ist ein Relikt aus den
Anfangstagen.

Bei aktuellen SSDs müßtest du die SSD mehrfach am Tag komplett
überschreiben, um diese innerhalb der Garantiezeit kaputt zu bekommen.

Wenn man ein paar Dinge beachtet, dann sind selbst Consumer-SSD
praktisch unkaputtbar.

1) Partitionen korrekt ausrichten, am Besten an Grenzen von vollen MB.
2) 10% bis 20% unpartitioniert lassen, das gibt dem Kontroller mehr
Platz um intern Daten umzusortieren und die Schreiblast klein zu
halten.
3) TRIM (discard) aktivieren oder regelmàßig "fstrim" ausführen.
Auch dies hilft dem Controller die interne Schreiblast klein zu
halten.

Beispiel aus meinem Laptop: Dort ist eine "Samsung 840" mit 256GB
verbaut, aus dem Jahr 2013.

In den 708 Laufzeittagen seitdem wurden 10,3TiB an Daten geschrieben,
also 41 Mal die Kapazitàt. Laut Controller der SSD hat dies 5% des
Wear-Leveling verbraucht, Sektoren selbst wurden noch keine umgemappt:

ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0
9 Power_On_Hours -O--CK 096 096 000 - 17015
12 Power_Cycle_Count -O--CK 098 098 000 - 1354
177 Wear_Leveling_Count PO--C- 095 095 000 - 57
179 Used_Rsvd_Blk_Cnt_Tot PO--C- 100 100 010 - 0
181 Program_Fail_Cnt_Total -O--CK 100 100 010 - 0
182 Erase_Fail_Count_Total -O--CK 100 100 010 - 0
183 Runtime_Bad_Block PO--C- 100 100 010 - 0
187 Uncorrectable_Error_Cnt -O--CK 100 100 000 - 0
190 Airflow_Temperature_Cel -O--CK 063 051 000 - 37
195 ECC_Error_Rate -O-RC- 200 200 000 - 0
199 CRC_Error_Count -OSRCK 100 100 000 - 0
235 POR_Recovery_Count -O--C- 099 099 000 - 58
241 Total_LBAs_Written -O--CK 099 099 000 - 22283546685

Wenn man dies also extrapoliert, dann wird die SSD weitaus lànger halten
wie das Geràt, in dem sie verbaut ist.

Mein Rat also: Pack auf die SSD drauf, was drauf geht, vor allem Swap
und die VM-Container profitieren _massiv_ von einer SSD.

Am Ende noch eine Artikelserie von Techreport.com, die in 2015 über
mehere Monate versucht haben, SSD mutwillig zu zerstören (und dies am
Ende auch geschafft haben, aber erst nach enormen geschriebenen
Datenmengen):

http://techreport.com/review/27909/...e-all-dead

Selbst die Samsung 840, die zuerst verstorben ist, hat dies erst nach
900TiB an Daten gemacht, wobei nach 100TiB die ersten defekten Sektoren
auftraten.

Umgerechnet auf mein Geràt erwarte ich also bei gleichbleibender Nutzung
die ersten Ausfàlle in 2020.

Grüße,
Sven.

Sigmentation fault. Core dumped.

Ähnliche fragen