[Linux] Welke partities op SSD?

[UPPERKEES]

Ik vraag mij af welke partities geschikt zijn voor een SSD. Met andere woorden snap ik dat bijvoorbeeld /var met veel log verkeer geen goed idee is voor de levensduur van zo'n schijf. Ook voegt het natuurlijk weinig tot geen performance boost op. Hieronder staat mijn schijf indeling, de dik gedrukte wil ik plaatsen op een SSD:

/boot 256 MB - ext2 rw,relatime,nodev,nouser,nosuid,async,auto
/ 2 GB - ext4 defaults
/usr 20 GB - ext4 rw,relatime,nodev,nouser,async,auto
/usr/local 4 GB - ext4 rw,relatime,nodev,nouser,async,auto
/var 10 GB - ext4 rw,relatime,nodev,nouser,nosuid,async,auto
/tmp 10 GB - ext2 rw,relatime,nodev,nouser,nosuid,async,auto
/swap 4 GB - swap sw
/home * GB - ext4 rw,relatime,nodev,nouser,async,auto

Ik wil graag jullie feedback horen of dit verstandig is. Ik wil de maximale performance maar ook een lange levensduur van de schijf, dus I/O verkeer moet minimaal zijn. Btrfs wil ik nog niet gebruiken omdat het nog niet uitontwikkeld is, daarom nog EXT4.


Alvast bedankt.

[Verwijderd]

Levensduur hoef je niet zo heel bang voor te zijn hoor; wat voor SSD heb je?

Je kunt je root ook prima op SSD plaatsen. Waarom gebruik je trouwens overal async voor? En wil je geen TRIM support inschakelen? In dat geval moet je discard als optie toevoegen.

Oh en /tmp kun je ook prima als tmpfs mounten, dus memory filesystem.

Dan zou je iets krijgen als dit:

/ 20 GB - ext4 rw,relatime,discard,auto
/var 10 GB - ext4 rw,relatime,nodev,nouser,nosuid,auto
/tmp - tmpfs
/swap 4 GB - swap sw
/home * GB - ext4 rw,relatime,nodev,nouser,auto

En eigenlijk zou ik /var ook gewoon op je SSD pleuren, maargoed dat ben ik.

[ Voor 6% gewijzigd door Verwijderd op 10-11-2011 13:29 ]

[UPPERKEES]

Ik heb nog geen SSD, ik doe alvast vooronderzoek ;-)

Ik had eens gelezen dat async snelheid winst oplevert omdat bij elke enkele lees actie ook een schrijf actie zou doen. Zover ik het had begrepen. TMPFS is een goede tip en ook discard!

Thanks!

[Verwijderd]

async betekent dat metadata niet in sync loopt met de data. Dit kan bij crashes en stroomfailures leiden tot een corrupt filesystem; niet aanbevolen in de meeste gevallen. Bij hardeschijven zorgt async wel voor een fixe snelheidsboost, doordat er minder seeks zijn. Voor SSDs zou het effect zeer beperkt moeten zijn.

async heeft alleen invloed op writes; reads blijven reads. De enige reden dat een read tot een write request zou leiden zijn de access times. Die kun je uitschakelen met noatime optie, maar relatime is ook bedoeld om de hoeveelheid atime-updates te beperken als ik mij goed herinner.

Ik de meeste gevallen: maak je niet zo druk om kleine dingen. Die discard optie is wel belangrijk. En het is ook veel makkelijker één groot filesystem van 20GB te hebben ipv vele kleine filesystems met een kleinere grootte. Dat je je home directory op je HDD zit is wel prima denk ik, en swap ook want dat wordt toch nauwelijks gebruikt.

Ik raad aan bijvoorbeeld een Crucial M4 64GB. Als je dan 50GB maximaal gebruikt in Linux haal je de maximale performance uit deze SSD. Meer ruimte heb je misschien toch niet nodig.

[UPPERKEES]

Nog een vraagje over TMPFS, ik lees hier dat het gebruik maakt van je RAM. De /tmp partitie wordt ook gebruikt bij het branden van een DVD bijvoorbeeld, als die groter is dan 4 GB dan heb ik never nooit genoeg geheugen daarvoor. Hoe werkt dit in de praktijk?

[Verwijderd]

Nouja het idee van /tmp is dat je daar geen heel grote bestanden naartoe schrijft maar iets wat er maar een minuut ofzo blijft staan.

Hoe tmpfs precies werkt onder Linux weet ik niet, onder BSD is het swap-backed dus uiteindelijk gebruik je dan wel je hardeschijf indien nodig.

Als je een DVD brand, gaat het dan een 4,7GB bestand naar /tmp schrijven? Niet direct de bestanden lezen vanaf de locatie waarvan je schrijft, dus on-the-fly? Ik dacht dat alleen vroeger met 1-2 speed CD-R branders het nodig was om een .iso te maken ipv direct bestanden wegschrijven.

[UPPERKEES]

Dan nog één vraagje omdat ik die even niet op internet kon vinden. Neemt zo'n tmpfs partitie gelijk ook 2 GB RAM in beslag wanneer je hem mount? Ik hoop het niet, ik heb namelijk slechts 4 GB. Ik ga mijn SWAP wel vergroten zodat ik altijd genoeg heb voor /tmp wanneer hij door zijn tmpfs heen is. Maar de memory claim van tmpfs wil ik wel graag weten, het klinkt in ieder geval als een mooie performance winst voor mijn systeem.

[Verwijderd]

tmpfs heeft als het goed is geen vaste grootte, maar past de beschikbare ruimte aan aan je RAM geheugen wat beschiktbaar is. Als je geen bestanden plaatst op een tmpfs bestandssysteem, dan is er ook geen ruimte in gebruik. Zet je er 20MB op, dan gebruik je dus ook maar 20MB RAM. Dit terwijl tmpfs rustig 15GB groot kan zijn als je 16GB RAM hebt. Een 'echt' memory filesystem dus, en niet zo'n block-device wat op memory staat met een normaal filesystem (ext4) erop, dat is oldschool en ouderwets.

[Verwijderd]

lvm (of btrfs, maar dat wil je niet), kies niet voor statische partities, dat is zo 1999 en onflexibel.

[ Voor 92% gewijzigd door Verwijderd op 11-11-2011 12:25 ]

[Verwijderd]

Als hij gewoon één partitie maakt op zijn SSD hoeft LVM ook niet, lijkt me. Want LVM had zo ook een significante impact op performance dacht ik?

[Q]

LVM is een extra laag en geeft een performance hit. Geen harde cijfers hoe groot die hit is en of die hit opweegt tegen de voordelen van LVM.

Voor thuisgebruik is het niet eens zo'n punt om bijna niet te partitioneren, dus alleen root, tmp en misschien nog /var op een aparte partitie maar meer niet.

[UPPERKEES]

Verwijderd schreef op donderdag 10 november 2011 @ 14:59:
Nouja het idee van /tmp is dat je daar geen heel grote bestanden naartoe schrijft maar iets wat er maar een minuut ofzo blijft staan.

Hoe tmpfs precies werkt onder Linux weet ik niet, onder BSD is het swap-backed dus uiteindelijk gebruik je dan wel je hardeschijf indien nodig.

Als je een DVD brand, gaat het dan een 4,7GB bestand naar /tmp schrijven? Niet direct de bestanden lezen vanaf de locatie waarvan je schrijft, dus on-the-fly? Ik dacht dat alleen vroeger met 1-2 speed CD-R branders het nodig was om een .iso te maken ipv direct bestanden wegschrijven.

Heb vandaag geprobeert een DVD te branden. Dit gaat niet met een 2 GB ramfs. Dus helaas.