SSD's en Linux: tips en trucs

[Mentalist]

SSD's zijn hot. Na een review als reviews: OCZ Vertex getest gaan steeds meer Tweakers overstag om er ook een te kopen.

SSD's vragen echter om een andere behandeling dan HDD's, ook wanneer het op software aankomt. Zodoende een topic met wat tips, en ook een paar vragen van mij die anderen misschien weer kunnen beantwoorden.

Partition alignment

Deze handleiding is voor de OCZ Vertex maar werkt wellicht ook voor andere SSD's. Hiermee maak je je SSD 512KB aligned. De handleiding gaat er vanuit dat je SSD op /dev/sda is te vinden.

fdisk -H 32 -S 32 /dev/sda

Door 32 heads en 32 sectors te gebruiken bereiken we 512KB brokjes.

Kies nu o (nieuwe partitietabel), n (nieuwe partitie), p (primaire partitie), 1 (partitie 1), 2 (begin bij cylinder 2, anders align je niet goed), kies het aantal gewenste cylinders, t (kies partitietype), 83 (type: linux), w (schrijven).

Controleer nu of het aantal heads en sectors klopt:

fdisk -l /dev/sda

Controleer nu de alignment:

fdisk -lu /dev/sda

Als het goed is start je partitie nu bij 1024.

VM writeback time

Linux kan schrijfacties bufferen om van meerdere acties één grote schrijfactie te maken. Ik heb er (nog) geen bewijs voor, maar vermoedelijk is dit over het algemeen beter voor SSD's. Zo controleer je hoe lang je systeem schrijfacties buffert:

cat /proc/sys/vm/dirty_writeback_centisecs

Vaak zal dit 500 zijn (5 seconden). Hoe meer hoe beter natuurlijk, maar bedenk je wel dat je dat kan verliezen bij een crash of stroomuitval. Met 500 verlies je dus hooguit 5 seconden data, met b.v. 3000 zou dat 30 seconden zijn. Zo pas je dit tijdelijk aan:

echo 3000 > /proc/sys/vm/dirty_writeback_centisecs
echo 3000 > /proc/sys/vm/dirty_expire_centisecs

Voeg het volgende aan /etc/sysctl.conf toe om deze wijziging permanent te maken:

vm.dirty_writeback_centisecs=3000
vm.dirty_expire_centisecs=3000

Swapfile

De beste optie hier: maak geen swappartitie op je SSD. Je sloopt hem voortijdig als deze swap ook echt aangesproken moet worden. Prop gewoon genoeg RAM in je systeem, of maak swap op een harde schijf naast je SSD. Verder is het aan te raden, al helemaal als je tòch eigenwijs swap op je SSD hebt, kernel swappiness op 0 te zetten:

Kernel swappiness is a controversial topic. The standard setting (60) for
kernel swappiness has the effect that inactive (but started) applications
will be moved to swap after some time. If the swap partition is placed
on a regular HDD in order to reduce wear of the SSD, then reloading the
application from swap can take several seconds. This causes annoying
delays and bad responsiveness of the system when you return from a
coffee break, for example. The solution is setting kernel swappiness
to zero, by adding a line vm.swappiness = 0 to /etc/sysctl.conf.
A temporary change for trying out the effect is possible by calling
echo 0 > /proc/sys/vm/swappiness (as root) from the command line.

Voeg dus "vm.swappiness=0" toe aan /etc/sysctl.conf.

Laptop mode

Laptop mode zorgt dat alle uitstaande I/O in één keer zal worden weggeschreven. Eén grote write is voor een SSD natuurlijk makkelijker te verwerken dan tig kleine writes aangezien er voor een kleine write, al is het maar een byte, een heel block moet worden gewijzigd.

Controleren of laptop mode actief is:

# cat /proc/sys/vm/laptop_mode

Laptop mode aanzetten:

# echo 5 > /proc/sys/vm/laptop_mode

Voeg "vm.laptop_mode=5" toe aan /etc/sysctl.conf om dit permanent te maken.

Overzicht /etc/sysctl.conf toevoegingen

vm.dirty_writeback_centisecs=3000
vm.dirty_expire_centisecs=3000
vm.swappiness=0
vm.laptop_mode=5

Geen accesstimes

Standaard schrijft de gemiddelde Linux distro een timestamp weg iedere keer dat je een bestand bekijkt. Dat resulteert in bijzonder veel schrijfacties waardoor je SSD vroegtijdig kan komen te overlijden door slijtage. Open /etc/fstab met b.v. nano, gedit, vim of wat je voorkeur maar heeft en zoek je SSD op. Voeg dan de optie "noatime" toe met een komma. Stond er bijvoorbeeld eerst "defaults", dan maak je daar "defaults,noatime" van. Als je de atime echt nodig hebt kan je ook relatime gebruiken:

relatime works by updating the atime field on disk only if the file hasn't been accessed since the last time it was accessed, (to provide the new email detection capability) or when the last access was more than 1 day ago (to help programs and users clean up unused files in the /tmp directory).

En desnoods kan je op nodiratime terugvallen, welke alleen voorkomt dat voor het lezen van een directory een update weggeschreven moet worden. Voor bestanden worden met nodiratime nog wel accesstimes weggeschreven. Noatime heeft dus duidelijk de voorkeur als je de accesstimes kan missen. Type "mount" in een terminal om te controleren of je het goed hebt gedaan. Zo staat er bij mij:

/dev/sda1 on / type ext4 (rw,noatime,errors=remount-ro,commit=0)

Sla tijdelijke meuk in je RAM op

Als je voldoende leeg RAM hebt kan je dit doen. Zo kan je bijvoorbeeld aan het eind van /etc/fstab het volgende toevoegen:

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

Zo heb je je /tmp voortaan in je RAM. Je kan ook /var/tmp en /var/log op deze manier in je RAM zetten als je dat wilt. Let wel op dat /var/tmp er is voor dingen waarvan programma's kunnen verwachten dat ze er na een reboot ook nog zijn, en logfiles in je RAM plaatsen heeft logischerwijs ook z'n consequenties.

quote: http://wiki.geteasypeasy...._Life_of_your_Flash_Drive

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/log/apt tmpfs defaults,noatime 0 0

Je kan op deze manier ook een map aanmaken voor andere dingen: maak een nieuwe map aan, b.v. /media/Ramdisk, en zet het volgende in je fstab:

tmpfs /media/Ramdisk tmpfs defaults,noatime,mode=1777 0 0

Standaard is tmpfs de helft van je RAM (let op: alleen wat je er echt opzet gaat ook van je RAM af, dus het kost niet half je RAM). Wil je een grotere tmpfs? Voeg size als optie toe:

tmpfs /tmp tmpfs defaults,noatime,size=3584m,mode=1777 0 0

Dit voorbeeld geeft een /tmp van 3,5GB.

Zet je firefox cache in je RAM

Browsercache geeft een aardig aantal writes (dus: slijtage) op je SSD terwijl het nut maar beperkt is.

Voor mij werkte deze truck niet, maar ik zal hem toch geven inclusief alternatief:

Type about:config in de adresbalk.
Klik rechts op een regel.
Ga naar new>string.
Voeg browser.cache.disk.parent_directory toe.
Sluit Firefox.
Ga naar about:cache om te controleren of het gelukt is.

Je kan ook je cache uitzetten: ga naar about:config en type in cache. Zoek browser.cache.disk.enable en dubbelklik erop. Dit kost natuurlijk wat performance bij het laden van webpagina's..

Ik heb het zelf nòg ingewikkelder aangepakt. Mijn cache staat in /tmp/FirefoxRamCache/Cache. Ik heb in /etc/rc0.d/ en /etc/rc6.d/ het volgende script, K99firefoxramcache:

code:

#!/bin/bash
tar --lzop -C /tmp/FirefoxRamCache -cf /tmp/FirefoxRamCache.tar.lzop Cache
cp /tmp/FirefoxRamCache.tar.lzop /media/harde/schijf/of/ssd

Dit maakt een archiefje van mijn cache en plempt dat op de HD. Bij het opstarten pak ik het weer uit:

code:

#!/bin/bash
mkdir /tmp/FirefoxRamCache
tar -C /tmp/FirefoxRamCache -xf /media/harde/schijf/of/ssd/FirefoxRamCache.tar.lzop

~/.mozilla/firefox/4387rnhv.default/Cache is een symlink naar /tmp/FirefoxRamCache/Cache. Zo kan ik dus iedere dag weer snel verder met de cache van gisteren.

I/O scheduler

Stukje Engels van het OCZ-forum, als er echt behoefte aan is vertaal ik het wel.

Changing scheduler could improve the speed of the SSD.
Originally Posted by Pigeon
Do not do not do not do not use the anticipatory (default for for 2.6 up to 2.6.18) scheduler or the cfq (default for 2.6.19-current) scheduler. These schedulers achieve a remarkable speedup on standard, platter hard drives by pausing after each read: usually after a process performs a read, it will read again (presumably grabbing another chunk of the same file) in quick succession. This trick will help alleviate seek times, which is the biggest detriment to hard drive performance. (note that at one point, this 'feature' of cfq was broken) You and I do not have this performance disadvantage. The noop and deadline schedulers do not perform this 'advanced logic' that serves little purpose for SSDs other than slowing them down.

However, deadline and noop are not created equal. Deadline will re-order reads and writes, attempting to decrease latency, etc. Noop will do absolute no logic of any kind - it is a simple fifo. It's really designed for people with dedicated RAID hardware that will perform all of this logic for them. Sometimes this is useful - if you have an eeepc and underclock it to 800MHz for maximum battery life, you really need every CPU cycle you can get, and noop can be a decent idea.

However, if you have a reasonably fast system, you're better served by deadline. It gives more priority to reads over writes: delays caused by waiting for io is typically caused because of a delay from reading, not writing.

To find out which schedulers are available on your system and which one is currently in use, use the command cat /sys/block/sda/queue/scheduler. The one in use is marked by [].

To temporarily change scheduler during runtime.

* Login as root [sudo -i]
* echo deadline > /sys/block/sda/queue/scheduler
* Logout the root shell [logout]

To make this change permanent you could add appropriate lines to /etc/rc.local. You could also edit /boot/grub/menu.lst.

Some remarks:

* Setting the scheduler should probably be done automatically during boot.
If there are only SSDs in the system and no regular HDDs, one can select
deadline globally by adding the kernel parameter elevator=deadline in the
kernel parameter line of the boot loader.
Another way is editing /etc/rc.local or /etc/init.d/boot.local,
depending on the Linux distribution. There one can directly add a line
echo deadline > /sys/block/sda/queue/scheduler
This will only change the scheduler for the specified device, so
this is the way to go on a mixed system with both SSDs and HDDs.

Using the kernel parameter in GRUB might not be permanent during a kernel upgrade.
Instead find the line beggining with # kopt=root=UUID= and add the parameter elevator=noop to it. Don't ever remove the starting # from this line.
When it's done, run the command sudo update-grub.

TRIM

For those unfamiliar with what TRIM is, it is a command the OS instructs to the drive to wipe invalid flash blocks when they are no longer needed. At present, when the OS deletes a file, only the file allocation table is updated to flag the space formerly used by the file as "unused". The problem here is that when this space is later overwritten, the SSD must first erase the blocks before it can write new data to them, which causes write performance to decrease. With TRIM support by the OS and drive, previously used empty space would no longer need to be erased before being written to.

TRIM zorgt ervoor dat je OS aan kan geven aan je SSD dat bepaalde blokken leeg mogen. Hierdoor heb je betere performance en kan de drive ook beter wear levellen waardoor je SSD dus gelijkmatiger slijt. Linux 2.6.28 heeft standaard ondersteuning voor TRIM, OCZ Vertex SSD's ondersteunen TRIM vanaf firmware 1.10.

Om TRIM in te schakelen moet je de mountoptie "discard" gebruiken. Deze kan je dus (met een komma) achter noatime zetten. (jordz. in "SSD's en Linux: tips en trucs")

Handleiding inclusief controle: http://askubuntu.com/questions/18903/how-to-enable-trim

Cache

Voor Windows bestaat er zFlashpoint, een programma/driver welke kleine writes cached. Bij SSD's zonder eigen cache (zoals de beruchte JMicrons) schijnt dit enorm te helpen. Dit is weer een vraag van mij: kan iets dergelijks ook onder Linux, of is dit wat dirty_writeback_centisecs al doet? Ik zou voor sommige machines een Jmicron SSD overwegen als dit onder Linux kan..

Oude Linuxinstallatie overhevelen

Als iemand nog tips heeft om een bestaande Linuxinstallatie over te hevelen op een netjes gealignede SSD hoor ik dat ook graag.

Ongebruikte programma's/services

..die kan je beter uitzetten. Als je distro bijvoorbeeld met Tracker of Beagle komt terwijl je de functionaliteit daarvan niet gebruikt, schakel het dan uit. Het scheelt een aantal writes geeft ook wat performancewinst.

Bronnen:
http://www.ocztechnologyf...um/showthread.php?t=54379
http://www.lesswatts.org/tips/disks.php
http://www.plugcomputer.o...x.php/Reduce_Flash_Writes

[ Voor 20% gewijzigd door Mentalist op 31-08-2011 00:12 ]

[Boudewijn]

Waarom wil je je SSD op 512kb alignen?

In hoeverre overlijden SSDs nog door write acties? Ik zie ook wel eens berekeningen voorbij komen waar uit het aantal writes afgezet tegen de levensduur blijkt dat dat best meevalt (en de drive na 10 jaar sneuvelt).

Standaard doet ubuntu op mijn laptop al relatime trouwens (9.04, geupdate vanaf 8.10). Het betreft een x301.


Gave thread!

[Mentalist]

Boudewijn schreef op maandag 27 april 2009 @ 02:51:
Waarom wil je je SSD op 512kb alignen?

SSD's schijven data per "blok", en zo'n blok is, iig bij de OCZ Vertex, 512KiB. Het kan dus performancewinst geven omdat wanneer de alignment niet klopt voor één schrijfactie mogelijk 2 blokken worden geschreven.

Bij OCZ Vertex en Intel SSD's is de performancewinst overigens beperkt, vooral bij JMicrons is het merkbaar. Of het ook voor de slijtage een positieve uitwerking heeft weet ik niet zeker, maar ik zou denken van wel.

In hoeverre overlijden SSDs nog door write acties? Ik zie ook wel eens berekeningen voorbij komen waar uit het aantal writes afgezet tegen de levensduur blijkt dat dat best meevalt (en de drive na 10 jaar sneuvelt).

Ik meen dat MLC zo'n 10.000 writes aankan. Verder is er natuurlijk nog niet veel praktijkdata beschikbaar, dus ik zou het zekere voor het onzekere nemen en overbodige writes minimaliseren.

Gave thread!

Thanks.

[Verwijderd]

Echt een mooi topic W3ird_N3rd Net als Boudewijn heb ik begrepen dat de huidige generatie ssd's heel wat write acties kunnen hebben. Maar ik moet zeggen ik ben geen deskundige op dit gebied.

[Dirk]

Voor wat betreft die writes kun je natuurlijk zelf ook heel eenvoudig een rekensommetje uitvoeren:
Neem de perfecte situatie voor wat betreft schrijfacties: altijd hele blokken.
Neem 50Gb writes per dag (best veel vind ik, voor een desktop iig)
Neem een SSD van 50Gb met MLC geheugen dat dus 10.000 writes aankan.
Bij perfecte wear-leveling zal elk blok nu elke dag een keer beschreven worden en zal de SSD dus 10000 dagen of 27,4 jaar meegaan.

Nu is de situatie natuurlijk niet perfect, voor wear-leveling zullen extra writes gedaan moeten worden om zo de weinig verplaatste / verwijderde data te verplaatsen naar een gebied waar al veel geschreven is om zo deze weinig beschreven gebieden weer beschikbaar te maken en daarnaast zullen writes ook niet altijd (zeg maar bijna nooit) precies een blok of een veelvoud groot zijn. Als je pech hebt zou dit de levensduur van de SSD met een factor 5 of nog meer kunnen verminderen.
Maar daar staat tegenover dat 50Gb aan writes per dag op een desktop zelden gehaald zullen worden. En als dat wel gebeurd, kun je natuurlijk ook gewoon een twee keer zo grote SSD kopen. Die heeft namelijk effectief ook twee keer zoveel writes.
Voor een server die heel veel writes uitvoert is een SLC SSD dan weer een prima overweging. Deze kan namelijk 100.000 writes aan, en gaat dus effectief tien keer zo lang mee. Wanneer er maar goede wear-leveling plaatsvindt zul je dus goed je best moeten doen om die binnen een paar maanden te laten overlijden.

[_JGC_]

W3ird_N3rd schreef op maandag 27 april 2009 @ 03:15:
[...]

SSD's schijven data per "blok", en zo'n blok is, iig bij de OCZ Vertex, 512KiB. Het kan dus performancewinst geven omdat wanneer de alignment niet klopt voor één schrijfactie mogelijk 2 blokken worden geschreven.

Niet alleen SSDs hebben daar last van, ook RAID controllers krijgen problemen als ze niet op de stripesize gealigned zijn. Om even voorbeeldje te geven:
Dell PERC4SC, 64MB, RAID-1 volume over 2x73GB 10K RPM disks.
hdparm test op /dev/sda: 60MB/s
hdparm test op /dev/sda1: 30MB/s

Verschil? sda is een raw device, sda1 is niet goed gealigned op de stripesize waardoor de controller zn logica in de soep loopt en sequential reads de helft trager worden.

[Boudewijn]

@Dirkw: is er een beetje een goede referentie over het maximale aantal write-ops per block op een willekeurige disk te vinden ? Als in: non-fabricant, maar third party?

[Dirk]

Hier staat er wat over, maar dat is weer fabrikant afhankelijk (onderaan het artikel):

For one thing, it matters whether the SSD drive uses SLC or MLC memory. SLC generally endures up to 100,000 write cycles or writes per cell, while MLC can endure anywhere from 1,000 to 10,000 writes before it begins to fail, according to Fujitsu's Hagberg. For its part, Western Digital's laptop hard-disk drive boasts up to 600,000 write cycles.

Waarbij je voor kwaliteits-SSD's er gerust vanuit kunt gaan dat er goede kwaliteit MLC-chips worden gebruikt, die dus 10.000 keer meegaan.

En:

But the myth that SSD drives can attain the same longevity as hard disk drives is true only in enterprise-class devices that have wear-leveling software in the drive's controller. This evenly distributes data across the device to ensure that cells do not wear out prematurely.

Welke wel leuk is, want tegenwoordig hebben de vertex en intel SSD's inderdaad wear-leveling, dus dan zou die claim nu wel kloppen.
Verder zou je tussen de bronnen van dit wikipedia artikel kunnen kijken. (Komt bovenstaande ook vandaan.)

[ Voor 5% gewijzigd door Dirk op 27-04-2009 14:45 ]

[Boudewijn]

Weet iemand hoe ik softwarematig mijn type disk kan vinden?
dmesg en fdisk geven weinig.

distro is ubuntu.

[deadinspace]

Leuk topic! Zeker tips als alignment en schedulerkeuze zijn interessant

W3ird_N3rd schreef op maandag 27 april 2009 @ 02:39:
Deze handleiding is voor de OCZ Vertex maar werkt wellicht ook voor andere SSD's. Hiermee maak je je SSD 512KB aligned. De handleiding gaat er vanuit dat je SSD op /dev/sda is te vinden.

Is 512KB-aligned wel nodig? Zou 4KB-aligned (of wat de blockgrootte van je fs dan ook is) niet genoeg zijn?

Het probleem voorzover ik het begrijp is dat je bijvoorbeeld 512 bytes MBR hebt, gevolgd door 1KB filesystem headers, gevolgd door heel veel 4KB filesystem blocks. In het eerste 512KB block van de SSD past dan dus de MBR (512B), filesystem header (1KB), 127 fs blocks (127*4KB). Daarna blijft er 2.5KB over waardoor het volgende fs block (4KB) half in het eerste SSD block past en half in het volgende.

Dan zou het voldoende moeten zijn als elk filesystem block in zijn geheel in één SSD block valt.

Zo heb je je /tmp voortaan in je RAM. Je kan ook /var/tmp en /var/log op deze manier in je RAM zetten.

Dat zou ik afraden voor /var/tmp en /var/log. Het idee van /var/tmp is expliciet dat daar dingen tijdelijk opgeslagen kunnen worden die na een reboot nog beschikbaar moeten zijn, en logs kunnen erg belangrijk zijn voor debuggen, forensics, en weetikwat.

...als je tòch eigenwijs swap op je SSD hebt...

Dat kun je wel eigenwijs noemen, maar als je wil hibernaten, dan moet je wel

[laurencevde]

Nog een heel belangrijk punt, imo belangrijker dan al het andere: bestandssysteemkeuze. Als je het aandurft(zoals ik) kan je het beste (het net in de kernel opgenomen en officieel nog niet stabiele) btrfs kiezen (in ssd-mode).
Ext4 doet het ook een stuk beter dan de oudere bestandssystemen. (benchmark: http://www.phoronix.com/s...=article&item=ubuntu_ext4)

De deadline-ioscheduler kan trouwens nog verder getuned worden (in /sys/block/sda/queue/iosched):
read_expire staat default bijv. op 500ms. Dat kan wel een heel stuk omlaag.

En Boudewijn, hdparm -I /dev/sda(hoofdletter i) geeft je alle info. Hoe zou je eigenlijk als third-party willen achterhalen hoe lang een disk meegaat? paar maanden lang je disk slopen met schrijfacties? Om het representatief te houden natuurlijk met meer dan 1 schijf... Duur geintje.

[Saturnus]

Leuke TS. Ook handig om toe te passen op gewone hardeschijven.

[Boudewijn]

laurencevde schreef op maandag 27 april 2009 @ 19:47:

read_expire staat default bijv. op 500ms. Dat kan wel een heel stuk omlaag.

En Boudewijn, hdparm -I /dev/sda(hoofdletter i) geeft je alle info. Hoe zou je eigenlijk als third-party willen achterhalen hoe lang een disk meegaat? paar maanden lang je disk slopen met schrijfacties? Om het representatief te houden natuurlijk met meer dan 1 schijf... Duur geintje.

Dat is wel het idee van wetenschappelijk onderzoek ja. Of intel zou een duidelijke transparante (wetenschappelijk gestaafde) onderbouwing moeten geven.


.

Ik zo eens hdparmen.

[Mentalist]

Dirk schreef op maandag 27 april 2009 @ 12:32:
Voor een server die heel veel writes uitvoert is een SLC SSD dan weer een prima overweging. Deze kan namelijk 100.000 writes aan, en gaat dus effectief tien keer zo lang mee. Wanneer er maar goede wear-leveling plaatsvindt zul je dus goed je best moeten doen om die binnen een paar maanden te laten overlijden.

Ik had wel gelezen (ik meen in een reactie op de FP) van iemand die een Mtron SSD met SLC geheugen in een database server had gestopt die ook logfiles bijhield.

Na een half jaar kon hij de SSD wegmikken. Dure grap dus op die manier.

Dirk schreef op maandag 27 april 2009 @ 14:43:
[...]

Waarbij je voor kwaliteits-SSD's er gerust vanuit kunt gaan dat er goede kwaliteit MLC-chips worden gebruikt, die dus 10.000 keer meegaan.

Ik heb zelf ooit mIRC, met chat logging aan, op een goedkope USB stick van 1GB gezet. Na een paar weken was die stick ook naar de mallemoer. Achteraf was het ook niet zo'n slimme actie, maar geeft wel aan dat flash dus zeker niet onsterfelijk is. Met wear levelling had hij het natuurlijk veel langer uitgehouden, en met wear levelling+cache mogelijk een eeuwigheid. Met cache had hij tenslotte niet voor iedere "LOL" op z'n donder gekregen..

deadinspace schreef op maandag 27 april 2009 @ 15:10:
[...]

Is 512KB-aligned wel nodig? Zou 4KB-aligned (of wat de blockgrootte van je fs dan ook is) niet genoeg zijn?

Dat weet ik het niet zeker (ik ben ook geen expert). Vista schijnt dat wel te doen, maar de originele schrijver van de handleiding op het OCZ forum zal ook niet voor niets voor 512KB hebben gekozen.

Het probleem voorzover ik het begrijp is dat je bijvoorbeeld 512 bytes MBR hebt, gevolgd door 1KB filesystem headers, gevolgd door heel veel 4KB filesystem blocks. In het eerste 512KB block van de SSD past dan dus de MBR (512B), filesystem header (1KB), 127 fs blocks (127*4KB). Daarna blijft er 2.5KB over waardoor het volgende fs block (4KB) half in het eerste SSD block past en half in het volgende.

Dan zou het voldoende moeten zijn als elk filesystem block in zijn geheel in één SSD block valt.

Ja en nee, SSD erase block size is 512KB. Als je 1 bit ergens wegmikt dan zal je SSD toch minimaal 512KB moeten trashen en eventueel herschrijven als er meer instond dan die ene bit.

[...]

Dat zou ik afraden voor /var/tmp en /var/log. Het idee van /var/tmp is expliciet dat daar dingen tijdelijk opgeslagen kunnen worden die na een reboot nog beschikbaar moeten zijn, en logs kunnen erg belangrijk zijn voor debuggen, forensics, en weetikwat.

Heb ik even erbij gezet. Of je dat doet hangt er dan vanaf hoeveel waarde je hecht aan het beschikbaar zijn van de info in die dirs na een reboot. Voor een CF-kaart ga ik ze iig naar het RAM moven, applicaties verzinnen de data in die dirs maar opnieuw als ze het nodig hebben..

[...]

Dat kun je wel eigenwijs noemen, maar als je wil hibernaten, dan moet je wel

Als je ook nog een harddisk ernaast hebt kan je daar je swap opzetten.

laurencevde schreef op maandag 27 april 2009 @ 19:47:
Nog een heel belangrijk punt, imo belangrijker dan al het andere: bestandssysteemkeuze. Als je het aandurft(zoals ik) kan je het beste (het net in de kernel opgenomen en officieel nog niet stabiele) btrfs kiezen (in ssd-mode).
Ext4 doet het ook een stuk beter dan de oudere bestandssystemen. (benchmark: http://www.phoronix.com/s...=article&item=ubuntu_ext4)

Ga ik eens naar kijken, lijkt me ook interessant.[edit]ext4 geeft alleen performancewinst begrijp ik. Altijd leuk natuurlijk, maar dat is ook nog eens getest op een JMicron SSD - de vraag is of de winst ook nog zo groot is op een fatsoenlijke SSD.

Ik vraag me af of het ook mogelijk is om softwarematig wear levelling toe te passen. Een CF-kaartje zou dan een stuk langer meegaan als bootschijf, en ik zou er best wat megabytes op de kaart en wat RAM voor op willen offeren.

Saturnus schreef op maandag 27 april 2009 @ 19:49:
Leuke TS. Ook handig om toe te passen op gewone hardeschijven.

Dat kan inderdaad ook prima. Processen optimaliseren voor minder writes zal ook met een harddisk in je systeem de performance verbeteren.

[ Voor 14% gewijzigd door Mentalist op 29-04-2009 03:35 ]

[Room42]

Goeie OP, Leuk hoor! Vooral het alignen is simpeler dan ik eerder dacht. Maar hoe re-align ik mijn huidige partitie? Wordt waarschijnlijk een nieuwe installatie (nouja, of ff m'n / tijdelijk kopieren naar een andere schijf).
Leuk ook de discussie die meteen op gang komt. Ben benieuwd wat voor tips en conclusies daaruit voortvloeien.

Over de slijtage maak ik mij tegenwoordig geen zorgen meer over. Ik denk dat echt schade door veel writes een oude mythe aan het worden is.

[ Voor 19% gewijzigd door Room42 op 29-04-2009 03:50 ]

[Mentalist]

Room42 schreef op woensdag 29 april 2009 @ 03:49:
Goeie OP, Leuk hoor! Vooral het alignen is simpeler dan ik eerder dacht. Maar hoe re-align ik mijn huidige partitie? Wordt waarschijnlijk een nieuwe installatie (nouja, of ff m'n / tijdelijk kopieren naar een andere schijf).

Ik ga denk ik proberen of ik niet gewoon eerst de partitie op mijn HD kan resizen (resize2fs+partitie verkleinen) en dan met dcfldd (dd variant) van de HD naar de gealignede SSD moven (b.v. van /dev/sda1 naar /dev/sdb1). Echt geen idee of dat gaat werken.

Over de slijtage maak ik mij tegenwoordig geen zorgen meer over. Ik denk dat echt schade door veel writes een oude mythe aan het worden is.

Ik weet het nog niet. Ik denk dat er over een zekere periode topics gaan opduiken van dode SSD's van mensen die accesstimes bleven schrijven.

Aan de andere kant, met wear levelling en cache vraag ik me ook heel erg af hoe lang dat zal gaan duren.

De tijd zal het leren. Je kan het ook moeilijk testen, want als je een benchmark 24/7 werk laat simuleren dan kan de cache veel beter ingezet worden en heb je dus nog geen goede test.

Jammer dat SSD's geen SMART-achtig iets hebben om te zien hoever ie versleten is.

[lamko]

Deze tweaks waren vooral handig voor OCZ v2 schijven die waren erg gevoelig, nu met de Vertex schijven is dit allemaal niet van toepassing (of mindere mate) en als je ook nog eens een slc schijf neemt heb je al helemaal nergens last van. Doelend op het hogere aantal schrijfacties per blok, waar je je dus minder druk om de writes hoeft te maken en bij slc hoef je je ook niet druk te maken om het alignen.
De korte writes waren gewoon een beperking van Jmicron controller.

Beetje kort verhaal maar ik hoor graag iedereen zijn mening erover.

ps
Heb zelf al een paar maanden een Mtron 3525 64 gb SLC schijf met Ubuntu 8.04 op mijn laptop.

[laurencevde]

Echt nodig is het met een vertex niet meer, maar de genoemde tips maken het er voor de drive wel makkelijker op, wat de performance iig niet negatief beïnvloedt...
Daarnaast is het ook nog helemaal niet bekend hoe effectief de wear-leveling van die drives zijn, en deze tips zorgen nog steeds dat de schijf minder hoeft te wear-levelen. Blijkt over een jaar dat de wear-leveling toch niet zo heel erg fantastisch is, heb jij er iig minder snel last van.

Het liefste zou ik trouwens een SSD zonder FTL (flash translation layer: flash-chips->block-device) hebben, waarbij linux dus zelf de flash-chippies kan aansturen. Geen dure controller-chip nodig, en je kan de uitstekende flash-bestandssystemen(met goede wear-leveling, goede performance) die voor linux beschikbaar zijn gebruiken. Maar ja zolang dat andere OS daar geen raad mee weet is zo'n schijf niet commercieel interessant...

Nou ja, ik heb hier nu al een tijdje een Core V2, en btrfs als FS doet het best aardig

[Mentalist]

laurencevde schreef op woensdag 29 april 2009 @ 22:57:
Geen dure controller-chip nodig, en je kan de uitstekende flash-bestandssystemen(met goede wear-leveling, goede performance) die voor linux beschikbaar zijn gebruiken.

Heb je hier meer info over? Een CF-kaartje heeft volgens mij geen of geen geweldige wear levelling dus daar zou het interessant voor zijn, dat is misschien ook wel de goedkope SSD die je zoekt.

[ Voor 4% gewijzigd door Mentalist op 30-04-2009 16:22 ]

[laurencevde]

Een CF-kaartje is IDE, en presenteert zichzelf als een block-device, en heeft dus een FTL aan boord(die niet altijd veel soeps is...). De MTD-bestandssystemen in de linux-kernel (jffs2, het nieuwere UBIFS, en het-niet-in-de-vanilla-kernel-aanwezige-maar-wel-stabiele-en-goed-werkende yaffs2) zijn bedoeld voor gebruik direct op flash-chips, zonder FTL(-controller) ertussen. Die werken erg goed, doordat (vooral jff2 en yaffs2) log-structured zijn, wat in de basis inhoudt dat alle aanpassingen incrementeel achter elkaar weggeschreven worden.
De linux-kernel heeft ook een block2mtd-driver aan boord, waardoor je jff2 en UBIFS op (oa) CF-kaartjes kunt gebruiken. Yaffs2 werkt niet, omdat die toegang nodig heeft tot de paar random-beschrijfbare bytes die elke NAND-flash-chip voor elk block tot zijn beschikking heeft(bedoeld voor wear-leveling...). Ik kreeg dat (op een korte test op m'n SSD) echter niet groter dan 2GB...
Je hebt dan echter wel 2 lagen wear-leveling boven op elkaar, waardoor het getalletje hoeveel keer een bepaald block beschreven is (wat de MTD-bestandssystemen (vziw) bijhouden) niet echt meer klopt...

Een FTL is een benaming voor de controller/het systeem wat de flash-chips als block-device bruikbaar maakt, met alles wat daarbij hoort(logisch->fysiek-block-mapping, random schrijfacties verwerken, wear-leveling toepassen). Die 3 genoemde bestandssystemen doen dat ook allemaal, maar ik durf te stellen dat, omdat het OS het zelf doet, ze het altijd beter zullen doen dan zelfs de meest dure en effectieve FTL in de schijf zelf. Ze hebben veel meer geheugen en processorkracht tot hun beschikking, hoeven geen rekening te houden met random schrijfacties/onhandige bestandssystemen, en weten wat wel en niet gebruikt wordt...

Ja, ik heb er een beetje onderzoek naar gedaan toen ik m'n SSD net had...

Offtopic: nee sorry, ik heb hier ook nog een atari 2600 waar we vanaf moeten...

[SirNobax]

Ik gebruik al een tijdje de bekende noatime en tmpfs truuk op de SSD van m'n Aspire One. Niet zozeer voor een langere levensduur maar om die write-'verstoppingen' te verhelpen. (zie JMicron Controllers, systeem word enkele seconden unresponsive)
Op een simpel apparaat wat geen databases of enorme logs bijhoudt lijkt me die 'wear' dan ook simpelweg onzin en flink overhyped. Tegen de tijd dat die SSD dood gaat, heb ik al lang een nieuwe SSD (of netbook for that matter).

[ Voor 8% gewijzigd door SirNobax op 01-05-2009 11:14 ]

[TheGhostInc]

http://www.ocztechnologyf...5632&highlight=linux+trim

Linux & Trim is nog geen werkende combi op de Vertex.

[Erhnam]

Gave thread! Jullie zouden ook eens kunnen kijken naar het xda forum en de android ontwikkeling. Hetzelfde probleem hebben veel hackers gehad bij het porten van Android naar hun HTC toestel. Daar zijn ook een aantal flashroms en kaartjes beschadigd doordat ze te vaak zijn beschreven.

[Mentalist]

Ik heb voor een systeempje een poor man's SSD: een 4GB Kingston Elite Pro 133x CF kaart met converter. Werkt op zich best goed. Als ik met

hdparm -d 1 /dev/hda

DMA forceer haal ik met hdparm -t bijna 40MB per seconde.

Helaas is Linux van mening dat ik verschrikkelijk dom ben en zet DMA bij het booten altijd voor mij uit. Heel verstandig maar niet heus, want dan haal ik nog maar 5MB/s. Ik heb libata.force=80c en libata.force=udma100 toegevoegd aan de kernel opties in /boot/grub/menu.lst maar dat helpt niet (80c is volgens mij niet meer nodig tegenwoordig trouwens). Ik heb het in /etc/modprobe.d/options gezet en update-initramfs -u gedaan maar dat helpt ook geen zier. Hoewel de suggestie op diverse plekken is te vinden schijnt dit helemaal niet te kunnen omdat libata een module zou zijn.

Hoe maak ik deze Debian install voor eens en altijd duidelijk dat dat kreng in DMA moet draaien, of hem dat nou verstandig lijkt of niet? In dmesg staat dit:

hda: hda1
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown (ja lekker behulpzaam)
hda: DMA disabled

Dat helpt dus ook niet echt.

[ Voor 7% gewijzigd door Mentalist op 11-06-2009 03:48 ]

[Room42]

Géén idee of het slim is, maar je zou "hdparm -d 1 /dev/hda" in de /etc/rc.local kunnen zetten.

[laurencevde]

Voeg eens libata.dma=7 aan je kernel-opties toe.

ff copy-paste uit de kernel-documentatie (als je de kernel-sources hebt geïnstalleerd, in Documentation/kernel-parameters.txt):

code:

        libata.dma=     [LIBATA] DMA control
                        libata.dma=0      Disable all PATA and SATA DMA
                        libata.dma=1      PATA and SATA Disk DMA only
                        libata.dma=2      ATAPI (CDROM) DMA only
                        libata.dma=4      Compact Flash DMA only
                        Combinations also work, so libata.dma=3 enables DMA
                        for disks and CDROMs, but not CFs.

Libata is een module die in de kernel-image, of in initramfs, ingebakken zit, en dus al lang geladen is tegen de tijd dat de losse modules gestart worden. Je hebt hem nu eenmaal nodig om je root-partitie te kunnen mounten... In /etc/modprobe.d/options kan je de opties waarmee een losse module geladen wordt neerzetten, maar dat heeft dus alleen effect voor losse modules. Modules die in de kernel ingebakken zitten zijn dan al geladen, en de opties daarvan moeten als kernel-optie meegegeven worden.

[Mentalist]

Room42 schreef op donderdag 11 juni 2009 @ 10:44:
Géén idee of het slim is, maar je zou "hdparm -d 1 /dev/hda" in de /etc/rc.local kunnen zetten.

Dat heb ik uiteindelijk ook nog gedaan, en toen kreeg ik gewoon 2x de DMA disabled melding in dmesg te zien.

Helemaal gek geworden ben ik toch de kabel maar gaan verwisselen, en dat leek enig effect te hebben. Met een andere kabel lukte het even om het iets langer te laten duren en ging hij meer geleidelijk, via UDMA66 en UDMA44 naar DMA disabled. Dat duurde 17 seconden iirc terwijl hij eerst na 3 tellen al disabled was. Ik heb nog wat andere kabels gecheckt, maar uiteindelijk start het systeem niet eens meer op met welke kabel dan ook. Ik dacht even dat het CF-kaartje b0rked was, maar een ander kaartje start evenmin. Alle cf2ide adapters die ik heb ik ook getest maar no dice. Zelfs een IDE kabel met 40 aders gepakt (die tot UDMA33 zou moeten limiteren), maar ook dat helpt niet.

Het zal dan toch wel een hardwareprobleem zijn maar ik ben hier nog niet klaar mee.

@laurencevde: thx voor de info. Komt wellicht nog van pas als de hardware een keertje meewerkt.

[ Voor 9% gewijzigd door Mentalist op 11-06-2009 13:54 ]

[Crakie]

In afwachting van mijn Vertexje even een vraag over dat tmpfs-trucje: hoeveel vrij geheugen is voldoende? Ik heb normaal gesproken 1,5 GB (van de 2) vrij met een paar programma's open. Lijkt me genoeg, maar ik kan me voorstellen dat bijvoorbeeld een dvd-tje fikken een flinke tmp-file genereert.

[cherwin]

Wel jammer dat de prestaties van een SSD omlaag keldert zodra die vol raakt, dat betekend dus dat ik meteen een "volle" SSD heb mocht ik die versleutelen met dm-crypt. Hoe gaan jullie daarmee om?

[SirNobax]

Crakie schreef op zaterdag 20 juni 2009 @ 17:03:
In afwachting van mijn Vertexje even een vraag over dat tmpfs-trucje: hoeveel vrij geheugen is voldoende?

Op mijn Aspire One, (met 1.5GB Ram, draaiend op Arch ) heb ik eens een VM van 1GB naar een tmpfs mapje gekopieerd ( ) dit ging, uiteraard, fout voordat hij klaar was. Ondertussen was er echter al wel zo'n 800MB overgepompt, dus om ruimtetekort maak ik me ook niet echt meer druk.

Laatst had ik nog wel wat troubles met een programma compilen (google earth geloof ik), terwijl ik /tmp (en /var/tmp) een limiet van 200MB had gegeven, dit gaf echter na 15 Minuten compilen dus gezellig de mededeling dat hij geen ruimte meer had. Na m'n fstab editen en een reboot was alles na 15 minuten gefixxed, om er uiteindelijk erachter te komen dat GoogleEarth met mijn GMA950 (met KMS ingeschakeld) zo'n 0.5fps haald.
Dus zodra je grote dingen wil gaan compilen (Open Office? ) denk ik dat je eventueel in de problemen kan komen.

@Cherwin
Al mijn geencrypte meuk zet ik op een externe 2.5" usb-hdd. Hetgene wat daar staat heeft ook niet echt baat bij reads van 200MB/s met minimale accesstimes.

[ Voor 16% gewijzigd door SirNobax op 23-06-2009 02:02 ]

[Crakie]

In dat geval lijkt de tmpfs op je ram zetten me niet echt de moeite waard. Over de extra writes maak ik me geen zorgen, de performancewinst zal ook niks bijzonders zijn. Ik denk dat ik me beperk tot de partition alignment, de noatime, de swap file en de scheduler. Simpele dingetjes zonder nadelen

[laurencevde]

Nou, mijn Core v2 is gisternacht overleden... Hij weigert nu elke schrijfactie, waarna de linux-kernel hem veel keer herinitïaliseert. Was afgelopen 3 maanden met btrfs geformatteerd. Data die erop stond heb ik nu maar weer naar een harde schijf verplaatst, en een image ervan gemaakt, maar een aantal bestanden waren corrupt, en daar ging btrfs niet zo heel lekker mee om (proces bleef hangen op die bestanden, en een flood aan kernel-messages...). Ik heb met enige moeite nu iig de bestanden in de partitie op die paar na naar de HD verplaatst. En weer een werkend systeem. (ja, ik heb een backup, van 3 maanden oud)
Die combinatie was dus niet zo heel erg geslaagd...

[_JGC_]

De Archlinux OpenOffice maintainer compileert OpenOffice gewoon vanaf tmpfs. Hij heeft 8GB geheugen en een SSD. Als zijn geheugen niet voldoende is groeit dat gewoon uit naar swap. Compilen op deze manier gaat gigantisch veel sneller dan vanaf een harddisk.
Zelf ga ik een dezer dagen een X25-M 80GB aanschaffen om mijn OS-disk te vervangen. De oude disk gaat gebruikt worden voor data, en zal ook de taak overnemen van mijn 2e 250GB disk die nu op sterven ligt sinds een paar stroomstoringen.

[lamko]

En wat is gigantisch veel ? Heb zelf een Slc schijf en deze draait nog steeds met volle tevredenheid.

[Kees]

lamko schreef op zaterdag 04 juli 2009 @ 14:45:
En wat is gigantisch veel ? Heb zelf een Slc schijf en deze draait nog steeds met volle tevredenheid.

Ik vind een vanilla kernel met default config compileren altijd wel een leuke test, gedeeltelijk de disk, cpu en geheugen. Mijn 'beste' resultaat tot nu toe met een 2.6.30 kernel is een compilate in 41 seconden op een raid-5 met 4 ssd's erin (en 24g geheugen, en gestart met -j 32).

Maar openoffice is een betere test, puur omdat die wat langer duurt, en meer ingewikkelde code bevat dan de kernel.

En gigantisch veel, dan heb je het over een compilatie tijd die 2-3 keer sneller is dan vanaf je hd, waarbij je het ook prima zelf kan testen, een programma compileren op een ramdisk zal iets sneller gaan dan op een fatsoenlijke ssd, en veel sneller dan op een disk, dus pak een favoriet groot programma, en compileer hem op je ssd, je disk en op een ramdisk, en kijk hoeveel sneller je bent

[Saturnus]

Maf vaag zeg...ik heb gewoon een HDD maar heb die 'VM writeback time' dus vergroot. Toch hoor ik om de seconde de hardeschijf (ja dat kan ook een leesactie zijn, maar wtf, dan nog...als er niets draait...). Op dat moment draaiden er 2 Virtual Machines. (XP en Ubuntu Server) Host OS is ook Ubuntu alleen de VM heeft geen GUI.
Hoe kan dat nou want die VM's horen praktisch idle te zijn. (Straks even test zonder VM's aan, maar ik geloof er niet echt in.)

[RemcoDelft]

Kees schreef op zaterdag 04 juli 2009 @ 15:45:
[...]
Maar openoffice is een betere test, puur omdat die wat langer duurt, en meer ingewikkelde code bevat dan de kernel.

Ik heb nooit de luxe gehad om OOo volledig op een ramdrive te compileren, maar als ik onder Gentoo normaal "emerge openoffice" doe, gebruikt-ie beide cores volledig. Harddisk-activiteit is zwaar beperkt, behalve bij het wegschrijven aan het eind. M.a.w.: wat mij betreft kan dit nooit 2-3 keer zo snel worden bij ramdrives, CPU is de beperking.

[!null]

Leuk topic. Ik ga wel even wat met tmpfs doen, daar iig /tmp/ opzetten en het firefox cache gebeuren, kijken of ik het merk. Misschien moet ik dan ook even kijken naar van die preload dingen. (maar dat staat los van SSD's)

Verder heb ik in m'n laptop een SSD, waar alles al op staat, gaat erg veel moeie kosten om dat over tezetten naar nieuwere filesystems.
Over de swap ben ik nog verdeeld, nu is ie nutteloos, die 1GB swap partitie wordt toch niet gebruikt (vanwege m'n 3GB ram) en als ik wil hibernaten heb ik een 3GB swap partitie nodig. Dat past eigenlijk niet, omdat ik maar een 16GB Mtron heb.

[Shadow_Dragon]

Voor de mensen die in het bezit zijn van een OCZ SSD 2de generatie (Vertex, Summit, ...) is er een post van Tony op het OCZ-forum met welke S.M.A.R.T.-waarden relevant zijn voor de betreffende SSD, met o.a. "D1 Remaining drive life in % by Erase count".

Omdat niet alle waardes relevant zijn heb ik een klein scriptje geschreven dat enkel weergeeft wat correct is en het past de "Attribute name" aan waar nodig. Beperkt het zoeken achter de juiste waarde.

code:

#!/bin/sh

# Syntax: filename [device]
# Requires: smartctl, head, grep, sed

sudo smartctl -A $1 | head -n 7
sudo smartctl -A $1 | grep "^\ \ 1\|^\ \ 9\|^\ 12\|^208\|^209" | sed 's/208 ....................... /208 Erase_Count_Average     /' | sed 's/209 ....................... /209 Disk_Life_in_%_By_Erase /'

[_JGC_]

RemcoDelft schreef op woensdag 15 juli 2009 @ 09:04:
[...]

Ik heb nooit de luxe gehad om OOo volledig op een ramdrive te compileren, maar als ik onder Gentoo normaal "emerge openoffice" doe, gebruikt-ie beide cores volledig. Harddisk-activiteit is zwaar beperkt, behalve bij het wegschrijven aan het eind. M.a.w.: wat mij betreft kan dit nooit 2-3 keer zo snel worden bij ramdrives, CPU is de beperking.

x86_64, flink overgeklokte Q6600, 8GB geheugen en een SSD. Compilen duurt gewoon een stuk langer vanaf hdd dan vanaf tmpfs + swap op ssd. Een dualcore max je redelijk uit op CPU tijdens het compilen, dat merk ik hier ook wel op mijn E6750. Een quadcore wordt gewoon tegengehouden door de disk tijdens het compilen. Let wel dat je bij 4-6 gelijktijdige threads veel last hebt van seeks, wat je bij 2-3 threads nog niet zo erg hebt.

[Quinny]

Iemand wel eens een SSD met Linux in een Asus EEE Box gedaan?

Als ik hem installeer zonder te alignen gaat alles goed, als ik de align-commando's uit de eerste post van dit topic uitgevoerd heb tijdens de installatie kan ik na de installatie niet opstarten. Ik krijg een cursor die om de paar seconden een regel naar beneden springt...

Voor mij dus maar even een niet gealignde Agility in m'n EEE Boxje...

[Saturnus]

"VM writeback time" wordt die verandering eigenlijk wel opgeslagen voor na een reboot?

En heeft iemand een command om te zien welke programma's gebruik maken van de swap?

[Quinny]

Saturnus schreef op zaterdag 25 juli 2009 @ 00:25:
"VM writeback time" wordt die verandering eigenlijk wel opgeslagen voor na een reboot?

En heeft iemand een command om te zien welke programma's gebruik maken van de swap?

In de eerste post van het topic staat dat VM writeback time niet opgeslagen wordt en dat je die regel in je rc.local moet zetten.

Programma's maken geen gebruik van swap; de kernel besluit wat er in de swap terecht komt en wat niet. Volgens mij is er geen manier om te zien wat er in de swap zit.


Niemand een idee waarom ik m'n partitie niet kan alignen?

[Shadow_Dragon]

De recente versies van hdparm komen nu gebundeld met een non-proprietary wiper-tool-script. Wipen is dus niet meer Windows-only.

[eghie]

Hier op deze site staan ook nog wat tips: http://itezer.com/blog/ub...Using-Linux-with-SSD.html

Deze optie komt er ook in voor:
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

Ik weet niet of het veel helpt by the way. Ik weet namelijk ook niet wat Linux standaard doet met z'n queue.

[Anoniem: 316584]

W3ird_N3rd schreef op donderdag 11 juni 2009 @ 03:26:
Ik heb voor een systeempje een poor man's SSD: een 4GB Kingston Elite Pro 133x CF kaart met converter. Werkt op zich best goed.

Heel mooi, ik ook. Weet je ook hoe deze ge-aligneerd moet worden? Ook 512Kb blokken?

[Mentalist]

Anoniem: 316584 schreef op dinsdag 01 september 2009 @ 22:38:
[...]

Heel mooi, ik ook. Weet je ook hoe deze ge-aligneerd moet worden? Ook 512Kb blokken?

Ik weet alleen maar dat die Kingstons verschrikkelijk snel naar de klote gaan. Vanaf het begin gaan ze 2 seconden na het booten van de DMA modus af waardoor ze trager worden, en binnen 10x booten werken ze compleet niet meer door corruptie.

Ik heb eerder Linux op een takeMS kaartje gezet dus het kàn wel, en ook van een USB-stick loopt het zonder al te grote problemen. Maar die Kingston bagger.

[Anoniem: 299176]

cherwin schreef op maandag 22 juni 2009 @ 18:28:
Wel jammer dat de prestaties van een SSD omlaag keldert zodra die vol raakt, dat betekend dus dat ik meteen een "volle" SSD heb mocht ik die versleutelen met dm-crypt. Hoe gaan jullie daarmee om?

De partitie 10% kleiner maken dan de totale groote van de ssd. Zo blijft er genoeg over voor WL en je snelheid zal minder snel inzakken.

[!null]

Binnenkort maar eens alles goed op een rijtje zetten. Ik ga dan terug naar Ubuntu 8.10 (vanwege bepaalde Intel hardware) met het ext3 filesystem, moet ik de boel toch opnieuw installeren dus kan ik meteen eventuele optimalisaties etc doorvoeren bij het maken van het fs.

[Anoniem: 299176]

laurencevde schreef op donderdag 25 juni 2009 @ 12:53:
Nou, mijn Core v2 is gisternacht overleden... Hij weigert nu elke schrijfactie, waarna de linux-kernel hem veel keer herinitïaliseert. Was afgelopen 3 maanden met btrfs geformatteerd. Data die erop stond heb ik nu maar weer naar een harde schijf verplaatst, en een image ervan gemaakt, maar een aantal bestanden waren corrupt, en daar ging btrfs niet zo heel lekker mee om (proces bleef hangen op die bestanden, en een flood aan kernel-messages...). Ik heb met enige moeite nu iig de bestanden in de partitie op die paar na naar de HD verplaatst. En weer een werkend systeem. (ja, ik heb een backup, van 3 maanden oud)
Die combinatie was dus niet zo heel erg geslaagd...

Dankje voor deze info. Ik heb destijds een ocz core v1 ext4 geïnstalleerd voor mijn vader. Had daar ook veel problemen mee. uiteindelijk heb ik ervoor gekozen om de home dir op de harde schijf te mounten, ivm schrijfactie van de user.

Maar als het goed is krijg je wel nog RMA. Dit kan je opzoeken op de site van OCZ. Die van mijn pa is ook al 2x naar ocz geweest. en heb ook 2x een nieuwe terug gekregen.

Ik heb nu zelf sinds kort en intel G2. Dag en nacht verschil. De GC van de nieuwe ssd's zijn vele malen beter Waardoor de snelheid ook constanter blijft.

[Anoniem: 299176]

Shadow_Dragon schreef op dinsdag 11 augustus 2009 @ 22:10:
De recente versies van hdparm komen nu gebundeld met een non-proprietary wiper-tool-script. Wipen is dus niet meer Windows-only.

Dit is goed nieuws voor de SSD's die het trim commando ondersteunen. Kon je ergens ook wel op wachten.

[Eusebius]

Goed topic, zit alleen met het volgende:

Liever geen swap gebruiken staat er in de FP. Hoeveel Ram moet je hebben om helemaal geen swap te gebruiken?

[!null]

Gebruik je alleen Text Editor of heb je vaak 30 GIMP schermen en 40 OpenOffice documenten open staan? Of game je er op?
Oftewel, zonder info moeilijk te zeggen.

Wat voordelig is in Linux dat ie je swap ook alleen gebruikt als het nodig is, niet alvast in gaat roeren zoals bij Windows.

Belangrijk is dat wil je kunnen hibernaten dat je een swap moet hebben die minstens even groot is als je hoeveelheid RAM.

[Eusebius]

!null schreef op maandag 14 september 2009 @ 11:38:
Gebruik je alleen Text Editor of heb je vaak 30 GIMP schermen en 40 OpenOffice documenten open staan? Of game je er op?
Oftewel, zonder info moeilijk te zeggen.

Wat voordelig is in Linux dat ie je swap ook alleen gebruikt als het nodig is, niet alvast in gaat roeren zoals bij Windows.

Belangrijk is dat wil je kunnen hibernaten dat je een swap moet hebben die minstens even groot is als je hoeveelheid RAM.

Sorry, heb me nooit zo in het concept SWAP verdiept. Er staan inderdaad regelmatig verschillende vensters van Gimp open verdeeld over 3 schermen (om boeken op te maken). Voor de rest veel fotowerk en natuurlijk het standaard surf & type gedoe. Ik heb 3 GB aan ram. De SSD had ik gekocht zodat ik helemaal geen draaiende schijf nodig heb, met uitzondering voor mijn dataschijf. Maar als ik blijkbaar wel een SWAP wil, zal deze beter op een ouderwetsche HDD moeten Of zijn er andere opties? Bv een 4 GB SSD kopen voor SWAP alleen? Als die ver****t wordt, dan is er weinig aan de hand.

[!null]

Draai je nu al linux? Kijk dan regelmatig even in hoeverre je swap gebruikt wordt (kan bijvoorbeeld met htop maar misschien ook al met standaard tools). Als er steeds niks of weinig in staat kan je gewoon op je SSD over gaan incl swap.
Meestal wordt een swap (bij zoveel RAM) amper gebruikt in Linux, dus kun je gerust het op een SSD zetten. Maar ik zou het gewoon regelmatig meten, als je toch al Linux draait. En SSD's worden ook beter, het is dan misschien ook niet echt een issue meer.

[ Voor 8% gewijzigd door !null op 15-09-2009 15:18 ]

[Eusebius]

!null schreef op dinsdag 15 september 2009 @ 15:18:
Draai je nu al linux? Kijk dan regelmatig even in hoeverre je swap gebruikt wordt (kan bijvoorbeeld met htop maar misschien ook al met standaard tools). Als er steeds niks of weinig in staat kan je gewoon op je SSD over gaan incl swap.
Meestal wordt een swap (bij zoveel RAM) amper gebruikt in Linux, dus kun je gerust het op een SSD zetten. Maar ik zou het gewoon regelmatig meten, als je toch al Linux draait. En SSD's worden ook beter, het is dan misschien ook niet echt een issue meer.

Ja, ik draai al Linux. En Windows. Weet niet precies hoe het zit met de SWAP onder windows, daar heb ik me nog niet in verdiept. Ik zit er nu wel aan te denken om een goedkoop / klein ATA SSD te halen (SATA zit vol) voor een schijf die bedoeld is voor SWAP en andere /TEMP of /Cache folders die veel herschreven worden (bv grafische software). Als deze schijf crasht, dan maakt dat niet minder uit.

Of haal ik met ATA een flessenhals in huis en kan ik beter een extra PCI kaart kopen?

[!null]

ATA zal ook snel genoeg zijn, alleen wat je erop aan gaat sluiten waarschijnlijk niet. Dan ga je naar goedkopere flash IDE modules kijken die al een iets slechtere access time hebben, tragere data rate, en veel IOPS ongetwijfeld niet aan kunnen. Als ie dan gaat swappen loopt het echt in de soep verwacht ik.

Ik zou eigenlijk gewoon alles op de SSD gooien, dan slijt ie maar iets sneller maar dan weet je iig zeker dat je vol profijt van de snelheid hebt. En nogmaals, ik denk zeker gezien swappen in linux dat het niet eens een echt issue is.

[Shadow_Dragon]

Eusebius schreef op dinsdag 15 september 2009 @ 14:34:
[...]

Sorry, heb me nooit zo in het concept SWAP verdiept. Er staan inderdaad regelmatig verschillende vensters van Gimp open verdeeld over 3 schermen (om boeken op te maken). Voor de rest veel fotowerk en natuurlijk het standaard surf & type gedoe. Ik heb 3 GB aan ram. De SSD had ik gekocht zodat ik helemaal geen draaiende schijf nodig heb, met uitzondering voor mijn dataschijf. Maar als ik blijkbaar wel een SWAP wil, zal deze beter op een ouderwetsche HDD moeten Of zijn er andere opties? Bv een 4 GB SSD kopen voor SWAP alleen? Als die ver****t wordt, dan is er weinig aan de hand.

Kort door de bocht:
SWAP heeft dezelfde functionaliteit als je RAM-geheugen. Gegevens waarmee de processor direct mee kan werken opslagen. Het grootte verschil tussen beiden is dat RAM-geheugen
1. Op speciale geheugen modules zit die zeer snel te bereiken zijn
2. Slechts gegevens kan bijhouden zolang er spanning op staat.
In tegenstelling tot SWAP dat
1. Een gebied je (zelf) kan alloceren op je HDD/SSD
2. Ook nadat de spanning er af gehaald is de gegevens behoud.

Vermits de gegevens waarmee de processor direct werkt, weliswaar gebaseerd zijn op de files van je HDD, maar helemaal niet hetzelfde zijn, is dat spannings-ding geen probleem + het is een goede orde sneller. Vandaar dat bijna alles in het RAM-geheugen geplaatst wordt. Tenzij in de volgende situaties
1. Je hebt zo veel programma's te gelijk lopen en openstaan dat je niet voldoende RAM-geheugen hebt om dat alles in te plaatsen. Dan kan je een deel van het (tragere) SWAP gebruiken.
2. Je wilt je computer / laptop in slaap-modus zetten waarbij de inhoud van je RAM-geheugen naar je HDD/SSD wordt geschreven voor een sneller opstarten de volgende keer.

Ikzelf heb geen SWAP nodig omdat,
1. 2 GiB RAM-geheugen heb en meestal op mijn Xubuntu daar maar zo'n goeie 250 MiB van benut, ruimte zat. (<-- Dit is iets dat je dus zelf eens moet opzoeken, wat dat hangt van gebruiker tot gebruiker vanaf)
2. Ik heb een SSD die mijn Xubuntu in 6 seconden boot en dat is snel genoeg voor mij, dus ik gebruik geen hibernate.

Dus gewoon alles op die SSD rammen zonder SWAP als je denkt dat je RAM-geheugen niet volloopt. Met 3 GiB RAM met een linux-based OS zal dat allemaal wel goed komen denk ik.

[!null]

SWAP gaat helemaal niks voor jou bijhouden als de spanning eraf is. Als de spanning weer op komt (dus een boot) dan begint ie gewoon overnieuw hoor. De SWAP wordt alleen offline gebruikt om te hibernaten, dan wordt je SWAP gevuld met de inhoud van je RAM op dat moment. Daarom dient een SWAP ook minimaal even groot te zijn als je RAM grootte, om te kunnen hibernaten.

Ik heb zelf 1GB SWAP genomen op 3GB RAM, waarbij de SWAP dus eigenlijk nooit gebruikt wordt. En nu kan ik dus niet hibernaten
(binnenkort even fixen)

[laurencevde]

Ook niet helemaal. VZIW hoeven in principe alleen de anonymous pages naar de swap te verhuizen. Dit is al het geheugen wat geen cache is, en geen ingeladen bestand is. Kan je zien in /proc/meminfo. Hier ongeveer de helft van het gebruikte geheugen. Je kunt dus in principe wel degelijk hibernaten met een swap die kleiner is als je ram. Als je niet zoveel open hebt staan zou je in principe in jouw situatie ook nog moeten kunnen hibernaten.
Maar het kan zijn dat de linux-kernel voor het gemak nog meer wegschrijft. Als je dan niet voldoende geheugen hebt, moet-ie op zijn minst weer losse bestanden, die niet in de swap pasten, weer gaan inlezen bij het resumen... Maar dat maakt niet zoveel uit op een SSD...

Maar dit gaat dan wel over de standaard hibernate van de linux-kernel, er zijn ook nog enkele alternatieve hibernaters voor linux...

Ikzelf zou iig wel de SWAP op de SSD zetten. De linux-kernel doet nogal veel random lees-acties bij het resumen, en dat is precies waar een SSD goed in is. Eventueel kun je je SWAP enkel aanzetten bij het hibernaten, en bij het resumen weer uit (swapon en swapoff)

[Borromini]

Saturnus schreef op zaterdag 25 juli 2009 @ 00:25:
"VM writeback time" wordt die verandering eigenlijk wel opgeslagen voor na een reboot?

En heeft iemand een command om te zien welke programma's gebruik maken van de swap?

Quinny schreef op zaterdag 25 juli 2009 @ 08:27:

In de eerste post van het topic staat dat VM writeback time niet opgeslagen wordt en dat je die regel in je rc.local moet zetten.

Toch even op inpikken - het is niet de bedoeling dat je zo'n commando's in je rc.local dumpt. Voor kernel settings is er het configuratiebestand /etc/sysctl.conf:

[stijn@hermes ~]$ grep writeback /etc/sysctl.conf
# Increase the VM dirty writeback time from 5.00 to 15 seconds
vm.dirty_writeback_centisecs = 1500

[!null]

@laurencevde, bij mij gaat hij op zwart bij hibernaten maar blijft aan staan, het mislukt. Mij is verteld dat dit komt door te kleine SWAP space, maar het hoeft niet zo te zijn. Als ik hem in standby wil krijgen komt ie er ook nooit meer uit

Verder ben ik dus zoals gezegd idd voor de SWAP op de SSD. Zeker in Linux, je gebruikt het zeer weinig en als je hem gebruikt dan is het erg fijn want het is precies waar een SSD goed in is.

Hoe geheugen gebruik verder is opgebouwd moet ik nog eens een keer goed op inlezen.

[ Voor 9% gewijzigd door !null op 24-09-2009 19:58 ]

[ejabberd]

laurencevde schreef op woensdag 29 april 2009 @ 22:57:
Het liefste zou ik trouwens een SSD zonder FTL (flash translation layer: flash-chips->block-device) hebben, waarbij linux dus zelf de flash-chippies kan aansturen. Geen dure controller-chip nodig, en je kan de uitstekende flash-bestandssystemen(met goede wear-leveling, goede performance) die voor linux beschikbaar zijn gebruiken. Maar ja zolang dat andere OS daar geen raad mee weet is zo'n schijf niet commercieel interessant...

Weet iemand hoeveel snelheidswinst je onder Linux zou krijgen als je een SSD zou gebruiken zonder FTL en zo'n controller chip? Hoeveel zou zo'n SSD minder kosten?

[Mentalist]

ejabberd schreef op zondag 25 oktober 2009 @ 11:57:
[...]

Weet iemand hoeveel snelheidswinst je onder Linux zou krijgen als je een SSD zou gebruiken zonder FTL en zo'n controller chip? Hoeveel zou zo'n SSD minder kosten?

Ik weet nog steeds niet hoe je erachter kan komen in hoeverre je USB-stick/CF/SD/etc-kaart aan wear levelling doet, maar een 16GB USB stick kost 25 euro. Dat zou een SSD dan dus ook ongeveer kosten. Je zou in principe ook best twee van die 16GB USB sticks moeten kunnen nemen en in RAID 0 zetten voor meer snelheid en RAM gebruiken als cache. Zelfde verhaal voor een paar SD/CF-kaartjes.

[ Voor 16% gewijzigd door Mentalist op 25-10-2009 12:22 ]

[jordz.]

Om TRIM/discard te enablen voor ext4, kun je sinds kernel 2.6.32 de mount optie "discard" gebruiken, deze staat standaard uit.

quote: http://osdir.com/ml/linux-ext4/2009-11/msg00268.html

+discard Controls whether ext4 should issue discard/TRIM
+nodiscard(*) commands to the underlying block device when
+ blocks are freed. This is useful for SSD devices
+ and sparse/thinly-provisioned LUNs, but it is off
+ by default until sufficient testing has been done.

[swbr]

jordz. schreef op zondag 20 december 2009 @ 19:01:
Om TRIM/discard te enablen voor ext4, kun je sinds kernel 2.6.32 de mount optie "discard" gebruiken, deze staat standaard uit.


[...]

Ik heb vandaag m'n OCZ Vertex 30GB binnen gekregen, Ubuntu 9.10 geinstalleerd en vervolgens maar eens de 2.6.32 kernelsource gedownload van kernel.org. De boel gecompileerd en er mee geboot, en de 'discard' optie is inderdaad mee te geven bij de mount opties. Echt getest heb ik (nog) niet, ik heb op dit moment nog geen idee hoe ik kan zien of die optie ook daadwerkelijk iets doet.

Wat me in elk geval wel opviel is dat hdparm -t op die nieuwe kernel nog maar ongeveer 80MB/s haalde, terwijl ik met de officiële kernel in de buurt van de 180MB/s kom. Ik hou het er op dat dat komt omat ik niet de moeite heb genomen om een fatsoenlijke 'make menuconfig' te draaien

[Mentalist]

Let iig op dat je de 1.4 firmware erop hebt staan, anders zal het sowieso niet werken.

Ik wacht denk ik maar op Lucid voor ik die firmware erop zet. Mijn Vertex is toch ondergepartioneerd en ik heb niet zo heel erg veel zin om zelf een kernel te compileren.

[swbr]

W3ird_N3rd schreef op donderdag 24 december 2009 @ 02:53:
Let iig op dat je de 1.4 firmware erop hebt staan, anders zal het sowieso niet werken.

Het ding kwam gisteren nieuw uit de doos, stond al netjes de 1.4 firmware op, dat had ik al meteen gecontroleerd

[Verwijderd]

Kan ik voor mijn Intel X25-M 160GB ook uitgaan van een 512KB alignment? Of toch voor 128KB gaan, aangezien dit de erase block size is van Intel, althans dacht ik ergens gelezen te hebben op Ts'o's blog.

[Shadow_Dragon]

Ehm, ik dacht dat die ook 512KiB hebben, maar dan nog, bij twijfel: speel op safe, 512KiB aligned is ook 128KiB aligned. (512 is een veelvoud van 128 )

[Boondock_Saint]

Goed topic! Over het plaatsen van swap partities op een ssd vond ik het volgende artikel uit december 2008 (!):

http://robert.penz.name/1...ling-filesystem-on-a-ssd/

En dat is al voor de tweede generatie ssd's.

Nu had ik zelf twee vraagjes aangezien ik net een nieuw systeem met een ssd heb gebouwd. Ik gebruik openSUSE en ik zag daar op een mailinglist (wel wat ouder ook) dat ze pas echt support van trim rond kernel 2.6.31/2.6.32 verwachten. Nu heeft openSUSE 11.2 kernel versie 2.6.31.5 en de development versie 2.6.32.
Moet ik dan voor de development versie gaan om het zeker te weten?

Verder vroeg ik me ook af of voor gen 2 ssd's het nog steeds aan te raden is om maar 90% van de ruimte te partitioneren?


De ssd is een Intel SSDSA2MH080G2C1 80GB

Overigens ga ik wel gewoon swappen op m'n ssd, na alle voor en tegenargumenten afgewogen te hebben. In het ergste geval heb ik ook nog een RAID 1 in m'n machine hangen waar de belangrijke bestanden op gebackuped staan.

[Dirk]

Over het eventuele nut van het gedeeltelijk partioneren van ssd's: reviews: Kingston SSDNow V 40GB en de volgende pagina. Mijn conclusie is dat dit onder andere afhangt van de gebruikte ssd en de eventuele aanwezigheid van TRIM.

[eymey]

Sorry, eigenlijk was deze post niet helemaal bedoeld voor dit SSD gedeelte

[ Voor 104% gewijzigd door eymey op 14-01-2010 15:19 ]

[Shadow_Dragon]

Boondock_Saint schreef op donderdag 14 januari 2010 @ 13:53:
Nu had ik zelf twee vraagjes aangezien ik net een nieuw systeem met een ssd heb gebouwd. Ik gebruik openSUSE en ik zag daar op een mailinglist (wel wat ouder ook) dat ze pas echt support van trim rond kernel 2.6.31/2.6.32 verwachten. Nu heeft openSUSE 11.2 kernel versie 2.6.31.5 en de development versie 2.6.32.
Moet ik dan voor de development versie gaan om het zeker te weten?

Voor zover ik de laatste geruchten heb opgevangen is dat ze een implementatie hebben, maar dat die nog niet voldoende getest zou zijn. Daarom zou TRIM-support default uit staan.

Boondock_Saint schreef op donderdag 14 januari 2010 @ 13:53:
Verder vroeg ik me ook af of voor gen 2 ssd's het nog steeds aan te raden is om maar 90% van de ruimte te partitioneren?

Als je TRIM werkt kan je de volledige ruimte gebruiken. De ruimte die je controller verborgen houdt is dan voldoende.
Als je nog geen TRIM heb zou ik voorlopig inderdaad een stukje HPA aanmaken. (Eerst cleanen met ATA-Secure-Erase natuurlijk, anders ben je er niet veel mee )

@eymey: Overgaan tot een aankoop kan alleen jij het beste beslissen.
Maar als als booten het enigste is dat van belang is, kan je dan niet gewoon een USB-stickje nemen, read-only booten (geen slijtage voor je stick door te schrijven) en al de rest op een RAM-diskje?

[eymey]

@Shadow_dragon, thanks toch alsnog voor je antwoord . De vraag heb ik nu in het algemene SSD topic gezet.

Ik heb geprobeerd om XBMC op een usb stickje te installeren maar die was daar zo traag bij dat het eigenlijk bijna geen doen was, dus durfde het ook al niet meer aan om af te wachten hoe snel die dan bij booten zou zijn. Op zich is XBMC er jusit wel een goede kandidaat voor omdat die zelf al heel weinig de noodzaak heeft te schrijven.

En een procedure zoals bij Ubuntu, dat er programma' tjes zijn die van een USB stick een mooi boot medium maken met een Casperfs-achtige constructie om veranderde data bij shutdown weer weg te schrijven heb ik voor XBMC ook niet gevonden (en is eik ook niet de bedoeling, want het systeem moet nog wel in redelijkheid een beetje snel kunnen booten).

[Boondock_Saint]

Shadow_Dragon schreef op donderdag 14 januari 2010 @ 14:37:

Als je TRIM werkt kan je de volledige ruimte gebruiken. De ruimte die je controller verborgen houdt is dan voldoende.
Als je nog geen TRIM heb zou ik voorlopig inderdaad een stukje HPA aanmaken. (Eerst cleanen met ATA-Secure-Erase natuurlijk, anders ben je er niet veel mee )

Als ik heel eerlijk ben ga ik de ssd volgende week pas kopen (heb de rest van het systeem gister gebouwd), dus dan zit het wel goed denk ik. fstab aanpassen zodat er gemount wordt met eerder genoemde vlaggen en dan gaan!

[swbr]

Shadow_Dragon schreef op donderdag 14 januari 2010 @ 14:37:
Voor zover ik de laatste geruchten heb opgevangen is dat ze een implementatie hebben, maar dat die nog niet voldoende getest zou zijn. Daarom zou TRIM-support default uit staan.

Geen geruchten. Zoals ik al eerder postte zit er in de 2.6.32 kernel echt TRIM support voor ext4. Het staat inderdaad wel default uit, maar door de optie 'discard' mee te geven zet je het aan.

Ik heb niet uitgebreid getest omdat ik geen zin heb om met een zelf gecompileerde kernel te draaien, maar het probleem dat het weggooien van files veel langer duurt omdat de manier waarop de blokken gewist worden niet lekker ging, lijkt in elk geval opgelost te zijn.

Het is dus in zoverre voldoende getest dat het wel in de nieuwste kernel zit, daar is het dus in elk geval stabiel genoeg voor. Door de optie nu 'in het wild' beschikbaar te maken komen er ongetwijfeld nog problemen naar voren, maar ik denk dat je die eerder op performance vlak kunt verwachten dan dat je data een risico loopt.

[Boondock_Saint]

Hmmm, na wat research komt er dus op neer dat ik of SUSE 11.2 neem en handmatig de kernel upgrade naar 2.6.32, met het risico dat sommige dingen niet meer werken.

Of ik neem de eerste milestone release die (hopelijk) uit komt op 21 januari, met het risico van een heleboel bugs.

Andere distros heb ik ook nog naar gekeken, maar die zitten (logisch ook) allemaal ook op 2.6.31. Ik werk zelf pas twee jaar met linux, dus zou iemand met meer (kernel upgrade) ervaring hier z'n licht op willen schijnen?

[Shadow_Dragon]

Antaresje schreef op donderdag 14 januari 2010 @ 21:07:
Geen geruchten. Zoals ik al eerder postte zit er in de 2.6.32 kernel echt TRIM support voor ext4. Het staat inderdaad wel default uit, maar door de optie 'discard' mee te geven zet je het aan.

Ik heb niet uitgebreid getest omdat ik geen zin heb om met een zelf gecompileerde kernel te draaien, maar het probleem dat het weggooien van files veel langer duurt omdat de manier waarop de blokken gewist worden niet lekker ging, lijkt in elk geval opgelost te zijn.

Het is dus in zoverre voldoende getest dat het wel in de nieuwste kernel zit, daar is het dus in elk geval stabiel genoeg voor. Door de optie nu 'in het wild' beschikbaar te maken komen er ongetwijfeld nog problemen naar voren, maar ik denk dat je die eerder op performance vlak kunt verwachten dan dat je data een risico loopt.

Zijt ge zeker dat die TRIM comando's ook effectief tot aan de drive geraken?
Zie hier een test om te checken of het wel lukt.
De Ubuntu Lucid Alpha 2 kernel (2.6.32.2) zou het blijkbaar nog niet doorgeven. Bron.

[Boondock_Saint]

Mede door de post van Shadow_Dragon heb ik besloten om toch gewoon voor 11.2 te gaan en dan over een paar maanden een nieuwe install te doen of eventueel tussentijds zelf de kernel upgraden.

Nu ben ik Suse aan het installeren en ik kan geen expliciete optie vinden om de partities te alignen, maar ik kan wel een block size per partitie opgeven met de waardes:

- auto
- 1MB
- 2MB
- 4MB

Als ik nu bijvoorbeeld 1MB kies, is de partitie dan ook direct aligned? Of is het beter om via een tweede shell in te loggen en de partities handmatig te alignen?

[Boondock_Saint]

Ok, ik hoop niet dat ik deze thread dood gevraagd heb

Voor andere users, ik heb het volgende gedaan:

- Met een live-cd geboot en iedere partitie aangemaakt met
fdisk -H 224 -S 56 /dev/sdc

Die waardes heb ik van deze blog. Daarna gewoon de stappen in de OP van deze thread gevolgd. Wel iedere keer gecheckt of de startcylinder deelbaar was door 8.

- M'n raid had ik er tijdens de installatie uitgetrokken, omdat dat problemen gaf met GRUB en SUSE perse van de raid wilde booten ipv de ssd.

Nu gaat het nog niet helemaal vlekkeloos omdat ie zegt "Waiting for /dev/sdc3 to appear" wat m'n root partitie is, daarna wordt gevraagd of er verder gegaan moet worden van device-id en dan werkt het wel. Maar goed, dat los ik nog wel op

[jeroen__online]

Ik heb deze thread de afgelopen week ook een paar keer geraadpleegd; vorige week heb ik m'n 40GB Intel SSD voorzien van een Debian Lenny (AMD64) installatie
@Boondock_Saint: De partitie heb ik uitgelijnd zoals in de SP staat:

code:

fdisk -H 32 -S 32 /dev/sda

Daarna heb ik een nieuwe kernel compiled, 2.6.32.7, met uiteraard ext4 support. Ik gebruik de SSD als bootdisk voor het rootfs in m'n server (zonder onderpatitioneren, geen swap), met daarnaast een software RAID1 array. Probleem is echter dat de standaard Debian kernel (2.6.26) geen ext4 support heeft en ik m'n rootfs dus als ext3 aan heb moeten maken. Ik las het bericht van Antaresje en kan mezelf nauwelijks inhouden m'n rootfs van ext3 naar ext4 te converten om het te proberen Ik heb een paar howto's gevonden en heb er wel enigszins vertrouwen in, maar als het misgaat ben ik uiteraard wel de sjaak
De stappen die ik vooralsnog heb ondernomen/in de planning staan om m'n rootfs te converten van ext3 naar ext4 (Debian Lenny AMD64):

• custom kernel compilen met ext4 support (2.6.32.7, gewoon met 'make oldconfig')
• GRUB updaten naar GRUB2, echter heeft GRUB2 pas vanaf versie 1.97 ext4 support, terwijl Debian GRUB2 1.96 verscheept: GRUB2 1.97 zelf compiled
• aangezien het m'n rootfs is: booten vanaf een andere linux-install met ext4 support, daarna m'n SSD converten naar ext4 (meer info hier en hier)
• m'n fstab aanpassen naar ext4 ipv ext3
• grub.cfg aanpassen, kernel optie 'rootfstype=ext4' meegeven
• hopen dat m'n rootfs goed mount bij opstarten vanaf de SSD
• discard-optie aanzetten op de ext4 partitie en checken of het daadwerkelijk actief is (thanks Shadow_Dragon voor de link om dit te testen)

Converteren is gelukt De eerste keer bootte ie niet, omdat m'n rootfs gemount werd als ext3. Na het aanpassen van grub.cfg (GRUB2 config, zie punt 5) was dit opgelost. TRIM is echter nog niet actief met m'n huidige 2.6.32.7 kernel en de 'discard' optie voor m'n partitie in fstab... Ik probeer zsm 2.6.33-rc7, die zou weer wat verbeteringen hebben mbt TRIM support.

Edit: met kernel 2.6.33-rc7 werkt TRIM prima

[ Voor 11% gewijzigd door jeroen__online op 07-02-2010 21:37 . Reden: nieuwe kernel compiled ]

[bas-r]

Interessant verhaal Jeroen!
Ik krijg deze week mijn Intel 40GB ssd'tje binnen en wilde voor de trim support Lucid Lynx installeren op mijn Laptop. Die heeft nog een 2.6.32.* kernel als ik het goed heb, ik ben benieuwd hoe goed TRIM voor mij zal uitpakken.
Kernels compileren doet me terugdenken aan 2001...

[TNW]

Misschien wel geen echte SSD maar:

Over een tijdje heb ik een CF naar IDE adapter binnen en die zou ik willen gaan gebruiken voor gebruik in mijn server (Ubuntu Server, Karmic, P3 800 MHz, 512 MB Ram, voornaamste bezigheden Icecast2, darkice, pptpd en LAMP (alleen voor Cacti zo'n beetje) ).
Op dit moment heeft deze het niet zo druk en zegt htop dat er maar 0 MB swap is. Ik zou swap dus kunnen uitschakelen.

Als ik de in dit topic genoemde tweaks voor Linux toepas zou het dan verder betrouwbaar moeten zijn of is er toch een significant verschil tussen "echte" SSD's en CF2IDE systemen?

De keuze voor deze oplossing is omdat ik de lawaaiige HD in mijn server wil vervangen door iets wat geen herrie maakt (staat op een logeerkamer) en omdat de huidige HD een radiosignaal uitzendt wat op apparatuur stoort. Verder is de HD veel te groot, ik ga nooit 80 GB in die server gebruiken, dus die HD zou ik dan weer elders kunnen inzetten.

[eymey]

Ik hoor veel mensen problemen hebben met het gros van de beschikbare CF2IDE systemen, al dan niet in combinatie met sommige merken en typen CF kaartjes.

Zelf krijg ik eerdaags een CF2SATA adapter met een 4 GB transcend 133x CF kaartje binnen, voor m'n XBMC pc (omdat ik de relatief dure OCZ Vertex 30G SSD daaruit bevreid heb). Zal m'n bevindingen hier posten.

Zelf ga ik tot op zeker hoogte denk ik wel optimaliseren, hoewel ik er nog achter moet zien te komen wat een goede alignment zou zijn. Maar sowieso, alle write-beperk-gerelateerde optimalisaties kunnen ZEKER geen kwaad .

[bas-r]

jeroen__online schreef op zondag 07 februari 2010 @ 15:17:
Edit: met kernel 2.6.33-rc7 werkt TRIM prima

Ik weet niet of je 'm zelf hebt gecompileerd, maar hier kun je .deb's voor Ubuntu Karmic downloaden: http://kernel.ubuntu.com/~kernel-ppa/mainline/

[ Voor 3% gewijzigd door bas-r op 19-02-2010 14:56 ]

[Boondock_Saint]

jeroen__online schreef op zondag 07 februari 2010 @ 15:17:
@Boondock_Saint: De partitie heb ik uitgelijnd zoals in de SP staat:

code:

fdisk -H 32 -S 32 /dev/sda

Ja ik had dat wel gelezen, maar Ted (niet dat ik 'm ken) heeft dezelfde ssd als ik, dus ik dacht ik neem die waardes maar

• discard-optie aanzetten op de ext4 partitie en checken of het daadwerkelijk actief is (thanks Shadow_Dragon voor de link om dit te testen)

Ik heb nu 2.6.33-rc8 en de test (die van Octoploid, eerdere link ging daar niet direct naar toe) werkte prima. Blocks werden bij mij gelijk gewist, zelfs zonder een paar minuten wachten zoals in die post staat.

[_JGC_]

Overigens moet je die intels op 128KB alignen, Intel heeft een 128KB blocksize. Alignen op een veelvoud mag ook, maar is niet nuttig.

Ik ben vorige week zelf met mijn 160GB SSD aan de slag gegaan. Eerst Vista eropgezet waar ik handmatig in de recovery console met diskpart de align= optie heb gebruikt om op 128KB te alignen. Elke volgende partitie heb ik met parted gemaakt en start en end met de hand uitgerekend steeds. Resultaat is helaas allemaal kleine gaatjes van 127,5KB tussen partities, omdat ik de end niet helemaal goed had.

[bas-r]

Met de tips van Jeroen_online heb ik mijn Intel X25-V in gebruik genomen.
Ook de grub.cfg willen editen om altijd rootfstype=ext4 mee te geven.
Ik kwam er toen achter dat het niet de bedoeling is grub.cfg te editten, en dat het beter is /etc/default/grub te editen, en vervolgens update-grub2 te runnen. In dat geval heb je bij een kernel update ook weer de juiste boot opties. http://ubuntuforums.org/showthread.php?t=1195275 (vanaf 5. Grub 2 Files & Options)

[Boudewijn]

Ik heb sinds iets meer dan een jaar een SSD in mijn thinkpad X301:

code:

ATA device, with non-removable media
        Model Number:       SAMSUNG MMCQE28G8MUP-0VA                
        Serial Number:      SE839B7403                              
        Firmware Revision:  VAM08L1Q

En ja die machine staat soms te swappen ondanks dat er 4GB mem in zit (moet eens kijken of ik 2x4 ipv 2x2 kan draaien), domweg omdat ik er lompe dingen mee doe (grote IDEs, debuggers etc).

Echter is de performance van die bak gewoon aan het inkakken, zeker bij IO activiteiten. Unrarren bijvoorbeeld duurt echt belachelijk lang.

Nu lees ik online weinig over de trim mogelijkheden van mijn SSD, ook omdat het al een oud model is.
Kan ik dat gewoon vergeten nu? Of zijn er toch nog wat dingen aan die snelheid te doen?

[Mentalist]

Boudewijn schreef op dinsdag 23 februari 2010 @ 23:30:
Ik heb sinds iets meer dan een jaar een SSD in mijn thinkpad X301:

code:

ATA device, with non-removable media
        Model Number:       SAMSUNG MMCQE28G8MUP-0VA                
        Serial Number:      SE839B7403                              
        Firmware Revision:  VAM08L1Q

En ja die machine staat soms te swappen ondanks dat er 4GB mem in zit (moet eens kijken of ik 2x4 ipv 2x2 kan draaien), domweg omdat ik er lompe dingen mee doe (grote IDEs, debuggers etc).

Echter is de performance van die bak gewoon aan het inkakken, zeker bij IO activiteiten. Unrarren bijvoorbeeld duurt echt belachelijk lang.

Nu lees ik online weinig over de trim mogelijkheden van mijn SSD, ook omdat het al een oud model is.
Kan ik dat gewoon vergeten nu? Of zijn er toch nog wat dingen aan die snelheid te doen?

Als je hem nog kan resetten op een of andere manier zou je hem denk ik kunnen onderpartioneren. TRIM zal er denk ik niet meer komen voor oudere SSD's.

[Boondock_Saint]

Boudewijn schreef op dinsdag 23 februari 2010 @ 23:30:

Nu lees ik online weinig over de trim mogelijkheden van mijn SSD, ook omdat het al een oud model is.
Kan ik dat gewoon vergeten nu? Of zijn er toch nog wat dingen aan die snelheid te doen?

Je kan proberen de firmware te updaten. Via de volgende link kan je een pdfje downloaden (rechts bij "Firmware dowload guide"):

http://www.samsung.com/gl...=161&partnum=MMCQE28G8MUP

Daarin staat hoe je de firmware kan updaten naar versie VBM19C1Q. Toen ik googlede op dat versie nummer kreeg ik de volgende link:

http://benchmarkreviews.c...sk=view&id=9246&Itemid=47

The new (free) Samsung VBM19C1Q firmware update now offers a TRIM/Garbage Collection for the OCZ Summit SSD. TRIM features are enabled under Windows 7, while Garbage Collection operates under Windows XP, Vista, OS X.

Maar dat gaat dus over de OCZ Summit! Of jouw ssd er ook TRIM door krijgt kon ik niet vinden.

[Wirf]

W3ird_N3rd schreef op maandag 27 april 2009 @ 02:39:

Oude Linuxinstallatie overhevelen

Als iemand nog tips heeft om een bestaande Linuxinstallatie over te hevelen op een netjes gealignede SSD hoor ik dat ook graag.

code:

cd /
tar cvpf - --one-file-system / | (cd /waar_je_ssd_gemount_is; tar xpf -)

Het alignen gaat automatisch goed omdat je daar aan gedacht had bij het maken van je partities (toch?)

Volgens Ted T'so kun je trouwens je Ext4 filesystem het beste zo aanmaken:

code:

mke2fs -t ext4 -E stripe-width=32,resize=500G /dev/sdb2

En vertrouw die Tedje maar, hij weet wel waar hij het over heeft

[ Voor 0% gewijzigd door Wirf op 26-02-2010 09:53 . Reden: p optie toegevoegd, staat voor "preserve ownership" ]

[Verwijderd]

Wirf schreef op donderdag 25 februari 2010 @ 21:35:
[...]

code:

cd /
tar cvf - --one-file-system / | (cd /waar_je_ssd_gemount_is; tar xf -)

Een onvoorwaardelijke tar-extractie na een cd is niet verstandig: als de cd om wat voor reden dan ook fout gaat (typo bv.) dan extract ie alles in de directory waar je al was. In dit geval zou je het complete root-filesystem over zichzelf heen kopieren, dan kon wel eens verrassende effecten hebben

Beter is om de ";" door een "&&" te vervangen:

code:

(cd /waar_je_ssd_gemount_is && tar xf -)

Iets soortgelijks geldt voor een rm-opdracht na een cd; hoe vaak ik dat al niet in scriptjes ben tegengekomen... potentiele tijdbommen.

Handig is de -C optie van tar, dan kan je de cd weglaten (en de haakjes zijn ook niet meer nodig):

code:

tar cf - -C / --one-file-system / | tar xvf - -C /path/to/ssd

En het tarren naar stdout (f -) is default (onder linux tenminste), dus hij kan nog korter:

code:

tar c -C / --one-file-system / | tar xv -C /path/to/ssd

[swbr]

Je zou ook nog van een live cd kunnen booten, dan weet je zeker dat je geen actieve files tegen komt bij het kopieëren. Het zal in de praktijk wel meevallen, maar toch.

[Wirf]

Verwijderd schreef op vrijdag 26 februari 2010 @ 08:49:
[...]dus hij kan nog korter:[...]

Volgens mij werkt dit ook: _{maar ik heb het niet geprobeerd}

code:

cp -ax / /path/to/ssd

[_JGC_]

Gewoon in single user mode booten, of zorgen dat er niks speciaals draait. Vervolgens met mount --bind stuk voor stuk je filesystem mounten op een directory in /mnt en met rsync -aH de data overzetten naar je SSD.

Op bovenstaande manier heb ik een paar weken terug de boel overgezet, alhoewel ik de oude disk aan eSATA op mijn desktop had zitten en de SSD al in mijn laptop zat, met daartussen een gigabit switch. Rsync werkt prima over SSH, werkt nog redelijk snel ook .

[KarlMarX]

Weet iemand een duidelijke (liefst Nederlandstalig) handleiding over hoe ik Ubuntu server op een Intel X25-V moet installeren en dan dus met de juiste uitlijning etc.

Ik kan wel handleidingen van OCZ vinden, maar voor een Intel SSD (40GB) zou het toch weer anders moeten.

Ook kan ik nergens duidelijk vinden of en hoe TRIM werkend te krijgen met Linux. Ik had zelf al mijn Ubuntu 9.10 installatie geupgrade naar een 2.6.33 kernel. Maar werkt TRIM dan vervolgens automagisch?

Ik loop nu al 3 weken te klooien met mijn SSD en linux. En ik krijg bijna de neiging om die SSD weg te doen en er weer een HD in te zetten (SSD's bewaar ik dan wel voor W7, daarmee werkt het tenminste wel out-of-the-box...)

[Dirk]

Partitioneren /alignen: W3ird_N3rd in "SSD's en Linux: tips en trucs". Op 512kb alignen moet op eigenlijk iedere SSD wel goed gaan. De rest zou ik negeren, dat zou een intelligente controller prima zelf moeten kunnen oplossen.
Alternatieve waarden voor alignment staan in Boondock_Saint in "SSD's en Linux: tips en trucs". Veel maakt het waarschijnlijk niet uit.
Voor TRIM zou ik Shadow_Dragon in "SSD's en Linux: tips en trucs" er eens bij pakken.

[jeroen__online]

KarlMarX schreef op maandag 15 maart 2010 @ 12:23:
[...]
Ook kan ik nergens duidelijk vinden of en hoe TRIM werkend te krijgen met Linux. Ik had zelf al mijn Ubuntu 9.10 installatie geupgrade naar een 2.6.33 kernel. Maar werkt TRIM dan vervolgens automagisch?
[...]

Zie de reactie van DirkW en mijn reactie hierboven, TRIM onder linux werkt *alleen* als:

• je kernel 2.6.33 of nieuwer hebt (met EXT4 en TRIM support)
• de partitie op je SSD gemount is als EXT4-filesystem (hiervoor moet je wellicht opties in je bootloader aanpassen)
• de partitie bij mounten de optie 'discard' meekrijgt in /etc/fstab

Vervolgens kun je testen of het correct werkt via de instructies van de link die Shadow_Dragon gaf. Succes