Hallo Leute,

habe mir gestern eine SSD (Samsung SSD 830, 128GB) gekauft und darauf mein ArchLinux System verschoben, das vorher auf einer "normalen" HDD lag. Außerdem habe ich diverse Maßnahmen ergriffen, um Schreibzugriffe zu verringern:

- AHCI im Bios aktiviert
- elevator=noop in der /boot/grub/menu.lst
- noatime,discard in der /etc/fstab
- vm.vfs_cache_pressure = 50 und vm.swappiness = 1 in der etc/sysctl.conf

/boot und /var und Swap sind auf der SSD /tmp ist tmpfs und /home habe ich auf der normalen HDD. Habe nun überlegt /var auch auf die normale HDD zu legen, um die Schreibzyklen weiter zu reduzieren. Viele Meinungen sagen aber auch aus, das dies übertrieben ist. So schnell sollen moderne SSD's dann doch nicht den Geist aufgeben!

- Aber das Loggen des Systems in /var (und was das System sonst noch alles auf die SSD schreibt) ist doch viel Schreiben oder?
- Reicht das automatische TRIM mittels discard? Habe auch schon öfters gelesen, dass man das manuell machen soll, weil die Automatik-Methode fehlerhaft sein soll!
- Muß ich Korrektes Alignment einstellen oder macht das der Kernel (aktuell 3.4.3) automatisch?
- Muß ich ein automatisches Defragmentieren abschalten?

Hat jemand von Euch schon Erfahrungen mit SSD's? Hätte gerne Eure Meinungen/Erfahrungen dazu!

Danke und Gruß
Chris
also ich habe seit letzem Jahr (August) eine SSD. Darauf sind drei Partitionen. swap, root und home.
Habe auch keine extra Partitionen für /boot /var oder so, alles in root.

meine Maßnahmen:

- GPT Partitionen (/ und /home) wegen Alignment
- mount Optionen defaults, noatime bei der /home Partition noch nosuid und noexec, aber eher aus Sicherheitsgründen
also SSD relevant nur "noatime"
- das TRIMMEN hatte ich zuerst per mount Option "discard" gemacht, jetzt aber über einen daily cronjob 
$ cat /etc/cron.daily/trim 
#!/bin/sh

/sbin/fstrim /
/sbin/fstrim /home
Bis jetzt läuft alles super und ohne Geschwindigkeitseinbußen. Habe sogar die swap Partition auf der SSD, aber die wird eh so gut wie nie benutzt da 8GB RAM vorhanden sind.
Ich bin der Meinung dass alles andere (Auslagern von /var usw.) irgendwie übertrieben ist.
Meine ganz unmaßgebliche Meinung zum Thema: Ich würde auf Minimierung der Schreibzugriffe keinerlei Rücksicht nehmen, ausser es macht auch von der Performance Sinn. noatime macht Sinn, vm.swappiness = 10 macht Sinn, da war wohl immer noch ein Bug, der kleinere Werte sinnlos und kontraproduktiv macht. Viel Arbeitsspeicher macht Sinn, /run, /tmp in tmpfs machen Sinn, Beachtung der Offsets macht Sinn.

Und regelmäßige Datensicherung macht auch Sinn. Bei der Entwicklungsgeschwindigkeit, den SSDs momentan haben, wäre es ein seltener Glücksfall, wenn man die Platten innerhalb des Garantiezeitraums gehimmelt bekommt, meine Vertex 2 ist jetzt knapp 2 Jahre alt und wird gegen eine Vertex 4 getauscht. (Mehr als doppelte Geschwindigkeit und Kapazität zum geringeren Preis als die Vertex II). Große Daten lagere ich eh auf meinen Datengräbern (Raid 1 mechanisch lokal oder Server mechanisch). Von daher würde ich das sportlich sehen und SSDs nicht bis an das natürliche Ende ihres Lebens nutzen wollen.
SiD schrieb- GPT Partitionen (/ und /home) wegen Alignment
Wie bootest Du dann? Grub funktioniert ja wohl mit GPT nicht!?
realdarkman schrieb
SiD schrieb- GPT Partitionen (/ und /home) wegen Alignment
Wie bootest Du dann? Grub funktioniert ja wohl mit GPT nicht!?
SYSLINUX 😉

EDIT:
Ach ja, und /tmp habe ich noch im RAM ...
Nutze Grub im MBR, ein parted /dev/sda align-check opt 1 gibt folgendes zurück:
1 aligned
Also ist das Alignment korrekt!?
realdarkman schriebSo schnell sollen moderne SSD's dann doch nicht den Geist aufgeben!
Also mein Arch läuft auf ner Vertex2 und das quasi seit dem es die Platten gibt. Nie Probleme gehabt.
Also die bemühungen die du da unternimmst halte ich für übertrieben. Sicher so biste auf der sicheren Seite so glaubst du. Doch ne normale HDD kann dir auch verrecken was machste dann? 😛
Einfach nen Script basteln für Backup dann nen CronJob und schon is alles tuti!
Stimmt denn das, das das AutoTRIM nicht richtig funktioniert?

  • [gelöscht]

  • Beitrag Nr. 10
Also bei mir läuft eine Crucial M4 seit Monaten in einem Macbook ohne zusätzlich im System aktivierte TRIM-Funktion. Der M4 geht es super, keine Einbußen zu verzeichnen.
und, who cares. Selbst die scheinbar geringen Werte von 3000 schreibzyklen müssen erst einmal erreicht werden. Das ist gar nicht so einfach. Und nach 2-3 Jahren ist eine SSD eh Sondermüll, weil um Längen zu langsam. Warten wir also mal die Entwicklung ab, in 2-3 Jahren kann eine Menge passieren.
agaida schriebMeine ganz unmaßgebliche Meinung zum Thema: Ich würde auf Minimierung der Schreibzugriffe keinerlei Rücksicht nehmen, ausser es macht auch von der Performance Sinn. noatime macht Sinn, vm.swappiness = 10 macht Sinn, da war wohl immer noch ein Bug, der kleinere Werte sinnlos und kontraproduktiv macht. Viel Arbeitsspeicher macht Sinn, /run, /tmp in tmpfs machen Sinn, Beachtung der Offsets macht Sinn.

Und regelmäßige Datensicherung macht auch Sinn. Bei der Entwicklungsgeschwindigkeit, den SSDs momentan haben, wäre es ein seltener Glücksfall, wenn man die Platten innerhalb des Garantiezeitraums gehimmelt bekommt, meine Vertex 2 ist jetzt knapp 2 Jahre alt und wird gegen eine Vertex 4 getauscht. (Mehr als doppelte Geschwindigkeit und Kapazität zum geringeren Preis als die Vertex II). Große Daten lagere ich eh auf meinen Datengräbern (Raid 1 mechanisch lokal oder Server mechanisch). Von daher würde ich das sportlich sehen und SSDs nicht bis an das natürliche Ende ihres Lebens nutzen wollen.
Kann ich nur beipflichten meine 16 GB Mtron (SLC 100€ !) läuft nun bestimmt schon 4 Jahre - ohne irgendwas spezielles zu tun,
agaida schriebund, who cares. Selbst die scheinbar geringen Werte von 3000 schreibzyklen müssen erst einmal erreicht werden. Das ist gar nicht so einfach. Und nach 2-3 Jahren ist eine SSD eh Sondermüll, weil um Längen zu langsam. Warten wir also mal die Entwicklung ab, in 2-3 Jahren kann eine Menge passieren.
Wie gesagt, meine SSD is inzwischen schon fast 2 Jahre und ich kann mich nicht beklagen.
Die einzige Klage, die ich hätte: 60 G sind für arch und siduction gemeinsam ein wenig knapp. Das ist aber eher ein Luxusproblem. Der neue Rechner wird nicht so sparsam ausgestattet, da kommen 3 Vertex 4 rein. Mit 120 G pro system muss das reichen.
30G pro / und mini-home. Das ist nicht mal Luxus, da bei debianoiden der apt-cache und bei arch die im ABS vorgehaltenen Pakete kommen. und das kann dann schon mal eng werden, wenn man wirklich mal das ein oder andere Gig zum testen braucht.
mmhh, meine root Partition ist 17GB und davon sind grad mal 8,5 belegt. Und ich leere auch nicht ständig den pacman cache ...
Und im /home sind grad mal 3,4GB belegt. Der Rest ist auf ner normalen HDD. 😉
rootfs 28G 19G 7.7G 72% /
1.2G /home/agaida
3.9G /srv/ISO

und der ISO-Ordner kann dann schon mal ein wenig größer werden im Laufe eines Tages. Vor allem wenn man grade bei Release-Vorbereitungen ist und wieder irgendwas in den Filesystemen kaputt ist. Klar kann man das auch ins Datengrab schaufeln. Wenn ich aber wirklich mal Images auspacken muss, um sie zu analysieren, mache ich das auf SSD, einpacken natürlich auch. Die Vorteile des hohen Durchsatzes will ich ja auch nutzen, ich hab mir das Zeug nich als Startbeschleuniger gekauft - das war eher ein netter Nebeneffekt. Und wenn die neue Maschine da ist, werde ich mir ganz genau anschauen, was mehrere Vertex 4 in einem Raid 0 bringen. Natürlich nur aus rein akademischen Gründen.

Nicht dass wir uns falsch verstehen, aber beim ISO-Bauen in einer Release-Vorbereitung habe ich es gerne schnell. Und wenn ich es durch den Einsatz von ein wenig Technik, fairen und unfairen Mitteln schaffe, dass so ein Distributions-Image in 3-4 min baut, dann tue ich das. Das reduziert den Stress ganz bedeutend, vor allem, wenn die Dinger nicht laufen und man debuggen muss.
Achso, son kram mach ich ja nicht.

Das einzige was ich außer dem Betriebsystem und /home noch auf der SSD habe ist die Virtuelle Festplatte für Virtualbox. 😉