Hallo,
Vorige week heb ik mijn eerste SSD gekocht (Samsung 840 Pro 256GB).
Nu is mijn vraag als ik openSUSE 12.3 er op zet moet ik dan nog dingen aanpassen?
Sinds ik een paar jaar geleden van een kernel-ontwikkelaar te horen kreeg, dat ik “niets” moest doen, gewoon behandelen als een willekeurige harddisk, doe ik niets op het gebied van “trim”, “noatime”, “elevator” etc. Heb in de 6 jaar die mijn oudste SSD is (draait/staat nu 12.2 op op mijn server) deze zeer heftig gebruikt (dagelijkse filetransfers van rond de 10.000 bestandjes per transfer) en het ding werkt nog steeds prima. Ben ook hier in de forums, en in mijn omgeving, nog niemand tegengekomen die echte problemen had met het “slijten” van een SSD.
Mocht je na een gewone installatie toch allerlei tweaks willen toepassen, dan kan dat alsnog.
Bedankt voor het antwoord.
openSUSE draait zonder problemen nu op de SSD.
Als je bij je SSD het onderste uit de kan wil halen qua levensduur en prestaties, dan kun je deze aanpassingen doorvoeren:
https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
Succes! 
Pjotr, als ik jou was zou ik de handleiding voor openSUSE’s herzien n.a.v. installatie op een eigen SSD. Kijk bijv. eens naar de fstab, die gisteren aangemaakt is:
/dev/disk/by-id/ata-ADATA_SSD_S511_120GB_22002979000000000103-part1 / ext4 acl,user_xattr,noatime,discard 1 1
/dev/disk/by-id/ata-ADATA_SSD_S511_120GB_22002979000000000103-part7 /Extra ext4 acl,user_xattr,noatime,discard 1 2
/dev/disk/by-id/ata-ADATA_SSD_S511_120GB_22002979000000000103-part6 /home ext4 acl,user_xattr,noatime,discard 1 2
/dev/disk/by-id/ata-ADATA_SSD_S511_120GB_22002979000000000103-part5 /srv ext4 acl,user_xattr,noatime,discard 1 2
Ik denk dat openSUSE ook de “trim” optie van ext4 aan heeft. De opties in de fstab, bedenk ik net, kunnen ook wel in een vorige installatie zijn toegevoegd, ik neem de partitionering altijd over, zou kunnen dat de hele fstab qua devices wordt meegenomen.
In het kort is dit de mening van openSUSE geleerden:
- elevator=noop op de kernel-parameter line
- discard, noatime in fstab
Output van een testscript geeft keurige output, trim werkt dus al op FS niveau. Volgende week moet ik nog 's installeren op een ultrabook (met i7, 16GB RAM, 256GB SSD), die ik als 't goed is helemaal leeg krijg, d.w.z. met een splinternieuwe SSD, zal ''s kijken wat de installer er dan van bakt. De bedoeling is dat er btrfs op gebruikt gaat worden, maar ik heb 'm een week in huis voordat mijn opdrachtgever terug is… en die vindt dat testen prima dus…
Bedankt voor het melden! Zoals ik ook al aangaf tijdens de presentatie, heb ik de SSD-handleiding voor openSUSE, slechts beperkt kunnen uitproberen. Als je de proef op de som wil nemen met een lege SSD en een schone installatie van 12.3, dan zou ik je erg dankbaar zijn.
Dingen die openSUSE al automatisch standaard regelt bij herkenning van een SSD, zijn belangrijk om te weten. 
Overigens is “noop” weliswaar een goede keuze als scheduler voor een situatie met uitsluitend SSD’s, maar minder goed in een hybride systeem waarin ook gewone harde schijven zitten. In die laatste situatie is “deadline” een betere keuze (beste compromis).
En het trimmen (discard) doe ik liever niet in fstab, omdat dit extra systeembelasting veroorzaakt bij elke bestandverwijdering. Ik geef daarom de voorkeur aan trimmen tijdens de opstart van het systeem (of wanneer het een server is, via een cron-taak).
“noop” inderdaad omdat ik alleen SSD in mijn laptop heb. Op mijn serverbak heb ik helemaal niets, ook geen “discard”.
“Lege” SSD’s om mee te testen heb ik niet. Ik ben financieel niet in de positie dat ik hardware kan kopen, puur om mee te testen. Een enkele keer “krijg” ik iets van een klant (recentelijk een Raspberry Pi) om “proof of concept” mee te leveren. Maar in de huidige tijd probeert men meestal om mij dit zelf maar te laten kopen :D.
Wat uiteindelijk mijn grote punt tegen het tweaken is, is dat ik vind dat de distro zodanig moet zijn, dat dit bij installatie opgevangen wordt. In dit geval, dat “noop” aangezet wordt bij slechts een SSD, “deadline” bij SSD + HDD, plus de optimale fstab entries. En dat kan prima; de NVIDIA driver installer zet toch ook KMS uit?
Mee eens. Maar zolang als dat (nog?) niet/niet helemaal gebeurt, kan het voordelen hebben om zelf in te grijpen. Voor geavanceerde gebruikers kan het zelfs een voordeel zijn: die vinden het sowieso vaak juist leuk om zelf aan hun systeem te knutselen. Daar ben ik er eentje van, in elk geval.
Overigens: met lege SSD bedoelde ik gewoon de SSD in die Ultrabook waar je over schreef… Niet letterlijk leeg. Ik ben erg benieuwd wat een schone installatie van openSUSE 12.3 op EXT4, voor fstab-waarden oplevert wanneer je het helemaal aan het installatieprogramma overlaat.
Ben daar al uit. Heb zoonlief even aan een clean install geholpen, die heeft mijn “oude” laptop, met 120GB OCZ. Geen “discard” of “noatime” in fstab. Ze er in zetten voor één partitie en dan de tests draaien vond ik een goeie. Reboot en dan zou-ie op de ene “trim” moeten gebruiken, op de andere niet. En, inderdaad. Nu staan zijn beide partities op “discard, noatiime” en dan de normale parameters.
Overigens gebruik ik, niet zozeer ontstaan om SSD als wel om hoeveelheid RAM, geen swap. Ik werk al sinds 5 jaar op machines met minimaal 4GB en kwam er achter dat de swap op alle machines alleen aangeraakt was tijdens installatie. Slapen enz. wordt hier niet gebruikt, behalve door mijn wederhelft (die als linux eenling in een grote schoolomgeving rondloopt dankzij mij, cool), maar die heeft voor dat doel juist een swap van 6GB (=RAM van haar laptop). heeft ook een gewone laptop schijf. Mijn advies aan mensen die naar SSD vragen is altijd: als je maar 2GB RAM hebt, doe daar dan eerst iets aan. Één van de dingen die me in de loop der jaren is opgevallen, is dat als er op SSD flink geswapt wordt de overall performance van het ding richting HDD naar beneden klapt.
Op mijn eigen laptop heb ik nog even geprobeerd of er verschil is in booten met of zonder discard (gewoon voor alles uitgezet, noatime ook), verschil was 13ms. in systemd-analyze blame. Die verwaarloos ik.
OK… en welke I/O scheduler pakt 12.3 standaard bij een schone installatie op een SSD? De traditionele cfq, of noop dan wel deadline?
Overigens zou je bij de keuze hoe je je trim laat gebeuren, pas na de opstart een snelheidsvoordeel moeten kunnen zien wanneer je trim niet via discard doet. Discard vertraagt de algehele systeemwerking iets, althans in theorie. Het zou vooral merkbaar moeten zijn bij het wissen van meerdere bestanden.
Het toepassen van trim tijdens de opstart van het systeem (boot.local), verlengt daarentegen de opstarttijd iets (oplopend tot enkele seconden, afhankelijk van de hoeveelheid die hij moet trimmen). Maar dat heb ik er wel voor over. Het lijkt me het beste compromis voor een bureaucomputer.
Booten is een prima optie om te meten begreep ik, omdat er dan in hoog tempo gelezen en geschreven wordt. Ben er overigens al lang achter dat er performancematig niet zoveel eer te behalen is op systemen als de mijne. Kwam ook nog een verhaaltje tegen van iemand die een SSD in een EEEPC met 1GB RAM had gestopt, en meende dat de SSD gewoon als HDD functioneerde :D, de snelheidswinst was bijna 0.
Hallo,
Moet ik nu wel of niet wat in openSUSE veranderen?
Als je 't jezelf makkelijk wilt maken, dan alleen
discard, noatime,
voor de mount-opties in de fstab zetten. Voor elke partitie op de SSD, behalve swap.