Ubuntu 14.10 op SSD

[xirerf]

Beste Tweakers,

Vandaag heb ik ubuntu 14.10 op mijn satellite u920t geinstalleerd. Nu lees ik overal op het internet nogal spannende dingen over een SSD in ubuntu. Een dagelijkse cron-job maken om de SSD te trimmen gaat nog wel lukken, maar ik lees ook dat het nogal het gebruik van de harde schijf als swap geheugen nogal problematisch kan zijn in linux. Nu is mijn vraag: is het slecht voor mijn SSD om linux te gebruiken als operating system? Onder windows doe ik nooit iets om mijn SSD te optimalizeren, dus ik weet niet hoe serieus ik de dingen die ik lees over vertraagde SSD's moet nemen. Als mijn SSD na drie jaar 10% minder snel is boeit me dat vrij weinig, maar als mijn SSD na drie jaar nog maar 10% van zijn originele snelheid heeft vind ik dat wel irritant.

Wat zijn jullie ervaringen wat betreft ubuntu op een SSD / ultrabook?

[CAPSLOCK2000]

Geen verschil met Windows. Onder Windows moet je ook je page-file niet op SSD zetten als je het ding zo lang mogelijk mee wil laten gaan. Een paar jaar geleden was dat ook echt een probleem, tegenwoordig is de techniek zo veel beter dat het niet veel uit maakt. Als je onder Windows niks speciaals doet is dat onder Ubuntu ook niet nodig. Als je wil mag het natuurlijk wel.

[ Voor 17% gewijzigd door CAPSLOCK2000 op 16-11-2014 17:24 ]

[jan99999]

Je hoeft niks te doen tav ssd, want de ssd's zijn een stuk beter geworden.
Wel installeren met AHCI in de bios installen tav controller.
Zelf heb ik in de fstab iet serbij gezet zodat ik geen cronjob hoef te doen.

[revertive]

As of Ubuntu 14.04, scheduled TRIM is enabled by default for Intel, SAMSUNG, OCZ, Patriot and Sandisk SSDs. If you have another brand, you could disable the vendor check by running the following command:
sed -i 's/exec fstrim-all/exec fstrim-all --no-model-check/g' /etc/cron.weekly/fstrim


(or just edit the file /etc/cron.weekly/fstrim and add --no-model-check)

Dus als je een SSD van Intel, SAMSUNG, OCZ, Patriot of Sandisk hebt staat trim standaard aan. En zet je swap partitie op een HDD als je die er ook in hebt zitten en anders kan je altijd nog een usbstickje pakken om je swap partitie kwijt te kunnen. Dit omdat swap soms nogal veel schrijf actie's nodig heeft.

[Blokker_1999]

met een moderne SSD zou ik zelfs geen probleem hebben met swap space op een SSD. Tegen dat je een SSD hebt kapotgeschreven heb je hem al lang opnieuw vervangen.

[Allard Pruim]

Ik heb mijn swap partitie gewoon op mijn SSD's staan omdat het dan in feite veel sneller werkt en ik denk dat dat geen problemen zou mogen geven. Wel is het zo dat in Ubuntu de swapneiging erg hoog staat waardoor de swap vrij snel wordt aangesproken. Of dit de levensduur van de SSD beïnvloed weet ik niet maar ik heb het aangepast naar een lagere waarde, namelijk naar 1. Standaard staat deze op 60 als ik me niet vergis.

En dat trimmen daar zou ik toch eventjes wat voorzichtig mee zijn, er zijn modellen waarvan de firmware problemen geeft wanneer de automatische trim in Ubuntu wordt uitgevoerd. Vandaar dat het ook alleen maar aanstaat op bepaalde SSD's van bijvoorbeeld Intel en Samsung.

code:

allard@ubuntu-pc-allard:~$ cat /etc/cron.weekly/fstrim 
#!/bin/sh
# call fstrim-all to trim all mounted file systems which support it
set -e

# This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty
# firmware may encounter data loss problems when running fstrim under high I/O
# load (e. g.  https://launchpad.net/bugs/1259829). You can append the
# --no-model-check option here to disable the vendor check and run fstrim on
# all SSD drives.
exec fstrim-all

Zie ook: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259829

[ Voor 63% gewijzigd door Allard Pruim op 16-11-2014 20:49 ]

[deadinspace]

bfrerix schreef op zondag 16 november 2014 @ 17:07:
... maar ik lees ook dat het nogal het gebruik van de harde schijf als swap geheugen nogal problematisch kan zijn in linux.

Ik heb dat nooit zo begrepen eigenlijk. Swap wordt meestal niet zo heel veel gebruikt; Linux gooit er wat ongebruikte stukken geheugen in en that's it.

Als je geheugen tekort komt, dan wordt swap aggressiever gebruikt, maar als dat gebeurt wil je dat swap op een snel medium staat. Daar heb ik juist een SSD voor, dus waarom zou ik die daar dan niet voor gebruiken?

Ik heb voor mijn desktop eens even gekeken om hoeveel het nou eigenlijk gaat. Op 17 dagen heeft mijn systeem ongeveer 15GB naar swap geschreven, en ruim 400GB naar de rest van de SSD.

Dat is bijna 1GB per dag aan swap writes, tegenover zo'n 24GB per dag aan normale FS writes. Mijn root fs (op de SSD) is ongeveer 19 keer zo groot als de swappartitie, dus de swappartitie ontvangt naar verhouding iets minder writes dan de rest van de SSD.

Nou verschillen dit soort dingen natuurlijk van systeem tot systeem, maar mijn vermoeden dat "omg! swap op een SSD" onzin was lijkt voor mijn systeem redelijk bevestigd

Nu is mijn vraag: is het slecht voor mijn SSD om linux te gebruiken als operating system?

Ik heb er juist zo veel mogelijk op staan. Ik heb een SSD om snel te zijn

Bij mij staan alleen media (films, series, muziek, etc) op een normale HD (via wat symlinks). Al het andere, inclusief swap, staat op mijn SSD voor snelheid.

Ik heb een Samsung 840 EVO, en een vlugge google leert me dat die ordegrootte 240TB writes zou moeten overleven. Met mijn 24GB/dag kom ik dan op een verwachte levensduur van 10 000 dagen. Swap of niet zou daarin weinig uitmaken (<5% van de writes). Nou is die duur vast wat optimistisch, maar weet je? Ik geloof het allemaal wel

[Hero of Time]

Leuk die getallen dat je noemt, maar wat kost meer: 100.000 write acties wat totaal 1 GB is, of 10 write acties wat totaal 100 GB is? Die eerste is veel zwaarder voor je SSD. Het is niet dat je grote hoeveelheden data wegschrijft, maar hoeveel acties dat vereist. Daarmee gaat je SSD eerder naar z'n einde.

[Blokker_1999]

Als je met 100k schrijfacties in totaal 1GB volschrijft of je schrijft met 10 acties 100GB vol ga je volgens mij toch echt meer cellen beschreven hebben met die laatste actie. Wanneer je 1GB schrijft met 10 acties of met 100k acties gaat die 100k natuurlijk wel zwaarder doorwegen. Maar daar een moderne SSD zonder problemen over de 1000k schrijfacties per cel geraakt mag ook dat geen echt probleem meer vormen. Tenzij je van plan bent om met je SSD +10 jaar te gaan werken

[deadinspace]

Hero of Time schreef op maandag 17 november 2014 @ 08:34:
Leuk die getallen dat je noemt, maar wat kost meer: 100.000 write acties wat totaal 1 GB is, of 10 write acties wat totaal 100 GB is?

Dat hangt af van de SSD in kwestie, het patroon waarmee je schrijft, en het gebruik van TRIM.

Die eerste is veel zwaarder voor je SSD.

Niet noodzakelijk. Sterker nog, die tweede kan 100 keer zo zwaar zijn (omdat het om 100 keer zoveel data gaat).

Als je ongebruikte ruimte (correct geTRIMd) van voor naar achteren vult, dan maakt het aantal writes waar je dat mee doet niet zo gek veel uit. Een geTRIMde erase block (EB) wordt in een SSD namelijk gemarkeerd als ongebruikt, en bij een write naar een page in die EB wordt het hele EB gewist, waarna de pages in die EB individueel beschreven kunnen worden zonder write amplification. (hier een aardige samenvatting van wat SSD internals)

Op zich maak je een goed punt mbt write size, maar ik ben er niet van overtuigd dat dat op mijn systeem significant verschilt tussen swap en het root fs, en wel om de volgende redenen:

• Als Linux pages van een process gaat uitpagen, dan probeert hij dat met meerdere pages tegelijk te doen (zie hier, 256KB in huidige kernels)
• Bij writes naar swap probeert Linux writes te groeperen tot grotere writes (zie hier, 1MB bij huidige kernels)
• Linux vult swap in grote lijn van voor naar achteren (zelfde bron als vorige puntje).

Al deze punten zijn vrij logisch; ze zijn nodig om een fatsoenlijke performance op klassieke harde schijven te halen (vergeet niet: seeks zijn enorm duur op die dingen).

Op een systeem waar swap maar lichtjes gebruikt wordt behalve voor hibernation (ook grote lineaire writes) verwacht ik dus dat de write patterns voor swap helemaal niet zo vervelend zijn voor een SSD.

Ik zou het eigenlijk wel interessant vinden dit verder uit te zoeken, en de daadwerkelijke write patterns te achterhalen. Misschien eens kijken of ik daar wat tijd voor kan vinden...

Volgensmij werkt bij mij TRIM helemaal niet door de dm-crypt layer heen, dus mijn aannames gaan niet helemaal op. Maar dat betekent dat TRIM ook niet voor mijn root fs werkt, dus dan ben ik overal even hard fucked

[begintmeta]

deadinspace schreef op woensdag 19 november 2014 @ 15:46:
...
Volgensmij werkt bij mij TRIM helemaal niet door de dm-crypt layer heen, dus mijn aannames gaan niet helemaal op. Maar dat betekent dat TRIM ook niet voor mijn root fs werkt, dus dan ben ik overal even hard fucked

Standaard worden discards inderdaad niet doorgegeven, maar dit kan bij dm-crypt (en ook LUKS) worden overruled door de gebruiker.

[xirerf]

Enorm bedankt voor alle reacties! Inmiddels heb ik Ubuntu 14.10 een aantal dagen geinstalleerd en ik moet zeggen: ik vind het een stuk fijner dan Windows.

Wel heb ik nog een vraagje. De internetsnelheden die ik haal zijn bijzonder variabel. Dat wil zeggen: via mijn wifi haal ik snelheden van 4Mbps tot 40Mbps. Zelfs als de ik met de router ben verbonden op 65Mbps haal ik soms maar 4Mbps binnen (via speedtest.net).

De wifi kaart is een intel Centrino-N 2230. Op ubuntuforums kan ik daar heel veel over vinden, maar alle fixes (zoals n protocol blokkeren, bluetooth uitzetten, etc. ) lijken geen verschil te maken. Weet iemand hier toevallig een fix voor?

[Allard Pruim]

Je zou eventueel deze website nog kunnen proberen, gemaakt door een lid van de Nederlandse Ubuntu Forum:

https://sites.google.com/...tip/geendraadloosinternet

[deadinspace]

begintmeta schreef op woensdag 19 november 2014 @ 16:19:
[...]

Standaard worden discards inderdaad niet doorgegeven, maar dit kan bij dm-crypt (en ook LUKS) worden overruled door de gebruiker.

Dat weet ik

Maar ik heb discard opgenomen als optie in /etc/crypttab, en het lijkt nog steeds niet te werken. Ik heb nog geen zin/tijd gehad dat verder uit te zoeken.

[daft_dutch]

In linux kan je het gedrag van swap veranderen met de swappiness settings.
http://en.wikipedia.org/wiki/Swappiness

als je ram zat hebt kan je je SSD ook extra sparen door je van je /tmp dir een ram disk te maken.
http://en.wikipedia.org/wiki/Tmpfs

[dennis_rsb]

Ik gebruik Linux Mint 17 Cinnamon, nu nog op een hdd om te testen maar wil hem waarschijnlijk op mijn SSD (Samsung EVO 840) installeren, ik weet dat Pjotr een hele website over het optimaliseren van SSD's heeft maar is dit echt nodig? Ik wil er gewone een goede snelheid mee halen en ook dat hij niet te snel kapot gaat. Onder Windows 7 heb ik ook nooit aanpassingen gedaan, en in Ubuntu/Mint staat tegenwoordig TRIM aan toch?

[CAPSLOCK2000]

Optimaliseren is niet nodig tenzij je het onderste uit de kan wil halen.

[Ultraman]

Ding gewoon gebruiken, daar zijn ze voor.
Ik heb hier een 50GB SSD van 5 jaar oud die er al zo'n 2.7TB aan writes op heeft zitten van allerlei orde. Ding doet het nog uitstekend. Maak je geen zorgen, dat gemiep over die levensduur is nergens voor nodig.
Ik wring mij ook niet in allerlei gekke bochten voor zo'n apparaat. Hoogstens zorgen dat trim werkt (via cronjob) en als het filesystem een optimalisatie voor een SSD heeft zet ik het aan.
Allerhande tweaks en mountpoints op verschillende schijven maken het alleen maar lastiger om te beheren en te overzien, zonder dat je er noemenswaardig op vooruit gaat.

[dennis_rsb]

Bedankt! Ik begreep dat TRIM opzich standaard al wel aanstaat vanaf 14.04 Ubuntu/Mint etc.? En ik las dat je hem ook af en toe handmatig kunt uitvoeren als je dat wil via de terminal?

[Thc_Nbl]

wat je hoogstens nog kan doen om je swap writes te verminderen, wat meer ram erin b.v. 4-8 minimaal.
en je swappines naar 20 of 10 zetten. Dat wordt eerst zoveel mogelijk geheugen gebruikt voordat hij gaat swappen.

verder geen zorgen met je ssd, ik zit nu op 2 jaar probleemloos met een ozc vertex 2 60gb.
bij installeren, mocht je handmatig partitioneren, zet "discard" aan bij je partitie parameters, en je trim staat aan.

en je trim testen ..zie hier : http://lightrush.ndoytche...onext4isenabledandworking

Je kan handmatig het commando fstrim / draaien, maar echt nodig is het niet.

[Ultraman]

fstrim -a aanroepen middels cron dagelijks of wekelijks, in plaats van "discard" in /etc/fstab er bij te zetten, kan een voordeel hebben voor de performance.

De "discard" optie zorgt ervoor dat de SSD een ATA TRIM commando gestuurd krijgt zodra een file wordt verwijderd. Zo'n ATA TRIM commando wordt direct uitgevoerd, in plaats van dat deze gequeued wordt. Hij gaat voor een wachtrij van uitstaande I/O operaties.
Ga je meerdere files verwijderen, dan volgt na elke verwijderde file een ATA TRIM. Deze zal de SSD eerst uitvoeren alvorens verder te gaan met het schrijven van bijbehorende meta-data (journal, eventueel diratime, e.d.), lees operaties en de verwijdering van de volgende file.
Aangezien schrijven voor een SSD een van de meer bewerkelijke acties is merk je dit in de performance wanneer veel kleine files worden verwijderd.

Door dagelijks of wekelijks een keer fstrim aan te roepen vind zo'n ATA TRIM op één moment plaats. Dat hakt er op dat moment even in, maar kun je natuurlijk (laten) doen op een tijdstip wanneer het geen probleem is.
Qua timing: als je voldoende vrije ruimte hebt en weinig met kleine files gooit (bv. compilaties) is wekelijks prima. Op mijn laptop heb ik zo'n 75~80% vrij van mijn 50GB SSD en doe ik niet veel I/O op kleine bestanden, hoogstens wat git repo bijwerkingen, daarop laat ik wekelijks een fstrim -a uitvoeren.
Op mijn desktop heb ik ook genoeg vrije ruimte, maar gooi ik veel meer met kleine files. Meerdere git repo's sowieso al. En wanneer ik aan het compileren ga en er meerdere 'make clean' operaties plaatsvinden kan er flink wat geTRIMed worden. Daarop draait fstrim -a dagelijks rond etenstijd.

Een methode om dit aan cron over te laten is door cron een scriptje te laten uitvoeren. Een methode hiervoor staat o.a. hier, nadruk op item 3: http://blog.neutrino.es/2...x-fstrim-lvm-and-dmcrypt/

Een uitzondering hierop is de vrije recente SATA 3.1 standaard. Zie: Wikipedia: Serial ATA
Deze introduceert "Queued TRIM commands" zodat zo'n ATA TRIM niet meer de command queue (de eerder genoemde wachtrij) voorbij gaat. Dat zal allicht wat schelen, al ben ik benieuwd wat de performance doet met de verwijdering van een grote boom van kleine files.
Wellicht een keer benchmarken wanneer ik SATA3.1 hardware in huis heb. Voorlopig nog niet iig...
Mochten je controller en SSD beide aan de SATA3.1 standaard voldoen, dan geldt bovenstaande verhaal in wat mindere mate.

Niet dat er verder iets mis is met "discard". Het doet wat het moet doen en is de meest simpele manier om het filesystem TRIM operaties te laten uitvoeren. Maar afhankelijk van het gebruik is het niet de meest performante.

Zei ik eerder nog iets over niet allerlei vage tweaks achterwege laten? Ik geef toe, dit is de enige die ik toepas. Maar een enkel cronjobje vind ik nog wel meevallen .

[ Voor 4% gewijzigd door Ultraman op 23-11-2014 22:22 ]