SSD's en Linux: tips en trucs

[Alexxxxxxxxxx]

Is dit ook van belang als je een langzame 8 GB SSD hebt?

[jeroen__online]

Alexxxxxxxxxx schreef op zaterdag 04 december 2010 @ 15:27:
Is dit ook van belang als je een langzame 8 GB SSD hebt?

TRIM, ext4 partities en de discard optie, is alleen nuttig als je SSD het ondersteunt Ik ken iig geen 8GB SSD die TRIM ondersteunt, dus ik vermoed dat het voor jou niet van belang is.

[Mentalist]

jeroen__online schreef op zaterdag 04 december 2010 @ 19:31:
[...]

TRIM, ext4 partities en de discard optie, is alleen nuttig als je SSD het ondersteunt Ik ken iig geen 8GB SSD die TRIM ondersteunt, dus ik vermoed dat het voor jou niet van belang is.

TRIM niet nee, maar de overige tips hebben natuurlijk des te meer effect op een tragere/kleinere SSD.

[Joshua]

Vanavond kan ik mijn SSD op het postkantoor ophalen (OCZ Technology 60 GB Vertex 2 Series SATA II 2.5-Inch Solid State Drive). Ik ga hier Ubuntu 10.10 op installeren (geen Windows of andere OS). Zijn er nog speciale dingen die ik moet doen?
Ik weet al dat ik TRIM support moet enablen door mijn fstab aan te passen.

[bas-r]

Joshua schreef op vrijdag 07 januari 2011 @ 10:37:
Vanavond kan ik mijn SSD op het postkantoor ophalen (OCZ Technology 60 GB Vertex 2 Series SATA II 2.5-Inch Solid State Drive). Ik ga hier Ubuntu 10.10 op installeren (geen Windows of andere OS). Zijn er nog speciale dingen die ik moet doen?
Ik weet al dat ik TRIM support moet enablen door mijn fstab aan te passen.

En juist alignen voordat je de partities aanmaakt. Lees hiervoor even dit topic door.

[xabre16v]

Joshua schreef op vrijdag 07 januari 2011 @ 10:37:
Vanavond kan ik mijn SSD op het postkantoor ophalen (OCZ Technology 60 GB Vertex 2 Series SATA II 2.5-Inch Solid State Drive). Ik ga hier Ubuntu 10.10 op installeren (geen Windows of andere OS). Zijn er nog speciale dingen die ik moet doen?
Ik weet al dat ik TRIM support moet enablen door mijn fstab aan te passen.

Ik heb de tips gevolgd van deze site: http://sites.google.com/site/computertip/ssd
Verder heb ik de swap partitie helemaal weggelaten maar wel geupgrade naar 8gb RAM.
TRIM aanzetten: http://askubuntu.com/questions/18903/how-to-enable-trim

Dan ben je er wel klaar voor

[Joshua]

Thanks! Zal zeker gebruik maken van deze tips. Helaas moet ik met dank aan de TNT wachten tot maandag voordat ik pas gebruik kan maken van mijn SSD.

[Joshua]

Ondertussen werkt mijn SSD naar behoren, TRIM staat aan en de SSD is juist gealigned zover ik weet.
Tevens heb ik een aantal dingen zoals mijn /tmp naar het RAM geheugen verplaatst en de tips uit de TS opgevolgt. Zijn er nog andere nuttige tips die de eventuele levensduur verbeteren of de SSD sneller maken?

[RielN]

code:

Schijf /dev/sda: 32.0 GB, 32017047552 bytes
255 koppen, 63 sectoren/spoor, 3892 cilinders, totaal 62533296 sectoren
Eenheid = sectoren van 1 * 512 = 512 bytes
Sectorgrootte (logischl/fysiek): 512 bytes / 512 bytes
in-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes
Schijf-ID: 0x000685dd

 Apparaat Opstart   Begin       Einde     Blokken   ID  Systeem
/dev/sda1   *        2048    14338047     7168000   83  Linux
Partitie 1 eindigt niet op een cilindergrens.
/dev/sda2        14338048    58593279    22127616   83  Linux
/dev/sda3        58593280    62531583     1969152   82  Linux wisselgeheugen

Mijn Vertex 30Gb SSD, is iets met partitie een. Alignment niet goed?

Performance is prima:

code:

/dev/sda:
 Timing cached reads:   6684 MB in  1.99 seconds = 3350.38 MB/sec
 Timing buffered disk reads:  592 MB in  3.00 seconds = 197.22 MB/sec

[Athius]

Kickje...

Ik heb vandaag een 60 gb vortex 2 in mijn eeepc (ubuntu 10.10 netbook edition) gemonteerd, maar het lukt mij maar niet om Trim aan de praat te krijgen. Ik heb de instructies van de link van
shadow dragon meerdere keren gevolgd, maar aan het eind blijft er date op de sector staan.
Aan de overige voorwaarden (linux kernel, ext4) voldoe ik allemaal.

Ik vermoed dat de fout in mijn fstab bestand zit, aangezien ik de instructies die hierover gegeven werden maar half snapte, maar ik heb geen idee waar de fout zich dan precies zou moeten bevinden.

Vandaar dat ik jullie lastigval (sorry!) met een ongelooflijke basic vraag, maar: Wat doe ik precies fout met mijn fstab file?

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid,noatime 0 0
# / was on /dev/sda1 during installation
UUID=4e8e2381-c064-4e94-99d2-fa8672c85f8a / ext4 discard,noatime,errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=de54d85e-c3f0-4505-9548-393a509a657d none swap sw 0 0

[xabre16v]

Toen ik nog een SSD had heb ik deze manual gevolgd en dat werkte prima:
http://askubuntu.com/questions/18903/how-to-enable-trim

[Athius]

Dank, deze keer werkte het wel.
Ik denk dat het vorige keer niet lukte omdat ik, of, geen reboot had gedaan na het aanpassen van mijn fstab, of omdat ik mijn home en niet mijn root als startpunt had gekozen.

Dit probleem is dus opgelost, maar ik heb nog wel een vraagje: Is er ook een manier om te verifieren of de 'noatime' instelling werkt?


Alvast dank,

Jasper

[H!GHGuY]

Athius schreef op zondag 03 april 2011 @ 13:26:
Dank, deze keer werkte het wel.
Ik denk dat het vorige keer niet lukte omdat ik, of, geen reboot had gedaan na het aanpassen van mijn fstab, of omdat ik mijn home en niet mijn root als startpunt had gekozen.

Dit probleem is dus opgelost, maar ik heb nog wel een vraagje: Is er ook een manier om te verifieren of de 'noatime' instelling werkt?


Alvast dank,

Jasper

code:

cat <eenfile>
stat <eenfile>

En dan naar de access time kijken.

[Mentalist]

Ik heb een paar dingetjes gewijzigd in de TS. Laptop_mode toegevoegd, een paar onderdelen in een logischere volgorde, fix voor dirty_writeback (dat kan je niet vanuit rc.local instellen) en linkjes naar TRIM-info. Als iemand een fout ziet graag melden, ik kan me natuurlijk vertypt hebben ergens.

Conservatief als ik ben heb ik vandaag pas de upgrade van Ubuntu 9.10 naar 11.04 uitgevoerd, overgegaan op ext4, mijn SSD gealigned en TRIM aangezet (nouja TRIM staat zelfs pas bij de volgende reboot aan, on the fly / remounten lijkt me niet zo snugger). Resultaat: van ~110MB/s naar ~185MB/s met hdparm -t.

[ Voor 14% gewijzigd door Mentalist op 21-05-2011 20:22 ]

[Theimon]

Ik heb zojuist een pricewatch: OCZ Vertex 2 SATA II 2.5" SSD 60GB aangeschaft. Ik heb het hele topic doorgenomen en zal zeker wat tips gebruiken zoals TRIM en alignment e.d.
Ik kon in dit topic echter niets vinden over de /var directory. Ik draai hier Gentoo ~AMD64 (kernel 2.6.39-r1) die alles compiled in een subdir van /var. Performance-wise is het dus interessant om /var op de ssd te zetten, echter; is dit met het oog op durability een wijze keuze?

Ik gebruik verder nog een Samsung F1 750GB als bulkopslag en een WD Velociraptor 300GB als huidige systemdisk. De WD zal dan "degraderen" naar een extra bulkopslag, maar zou ik een aparte /var op deze hdd moeten zetten, of is de impact van een dergelijke hoeveelheid read/write te klein om de levensduur serieus in gevaar te brengen?

Het is een desktop pc, dus ik heb geen database of zware mail applicaties in /var staan. Dat scheelt uiteraard ook.

[Mentalist]

Ik zou /var op de Velociraptor zetten in dit geval: het scheelt flink wat writes en qua performance maakt het toch niet zoveel uit omdat je bij compileren vooral op je CPU zit te wachten.

[ Voor 3% gewijzigd door Mentalist op 18-06-2011 17:45 ]

[Theimon]

Zo'n idee had ik al, ik kon er alleen niks over vinden. Bij zoektochten op /var en ssd's kom je toch vooral opmerkingen over mail en databases tegen. Eerder server-gerelateerd dus.

[Ultraman]

Syncen van je ebuilds tree zal op de SSD wel een stuk sneller zijn. Maarja, dat is iets wat je misschien een keer per dag doet? Als je de mogelijkheid hebt zou ik /var lekker op de Velociraptor zetten. En mocht je snel willen compilen, dan kun je dat in RAM doen.
Ik heb op mijn laptop /tmp in het RAM gemount dmv tmpfs. Daar gooi ik downloads naar toe, ik extract er files en ik compileer er wel eens een package. Dingen die je wilt bewaren er af kopiëren natuurlijk.
Ik heb voor mijn laptop zitten overwegen om een SD-kaartje te misbruiken voor mijn /var, of iig /var/log en /var/cache, maar daar ben ik niet aan begonnen. Want als ik dan een keer een SD-kaartje zou willen lezen...

[ Voor 18% gewijzigd door Ultraman op 18-06-2011 22:31 ]

[Theimon]

Een Portage sync gebeurt inderdaad eens per dag, daar valt dus geen winst te halen. Downloads en extractions gebeuren nu op de Velociraptor en dat gaat op zich snel genoeg.

Dan ga ik maar eens de boel back-uppen. * Theimon gaat voor een fresh-install. Kan geen kwaad, er staat her en der wat oude losse meuk tussen. Even schoon schip maken dus.

[Verwijderd]

Ultraman schreef op zaterdag 18 juni 2011 @ 22:29:
En mocht je snel willen compilen, dan kun je dat in RAM doen.
Ik heb op mijn laptop /tmp in het RAM gemount dmv tmpfs. Daar gooi ik downloads naar toe, ik extract er files en ik compileer er wel eens een package. Dingen die je wilt bewaren er af kopiëren natuurlijk.

Oeeeh pitty! Uit veiligheidsoverwegingen zou ik /tmp nooit mounten zonder noexec. Je kan nog steeds een andere dir mounten als tmpfs om te compilen.

[Theimon]

Als ik de ssd check volgens deze methode dan werkt TRIM in ieder geval prima Verder kom ik met de hdparm-tests op prima resultaten.

/var staat apart op de Velociraptor, waar ik qua prestatiewijs vrijwel niks van merk. De algehele responsiveness van het systeem is dankzij de ssd er wel degelijk op vooruit gegaan. Het voelt allemaal wat vlotter aan.

Verder heb ik swap volledig eruit gegooid. 8GB RAM moet genoeg zijn. Net ook nog even Cool 'n Quiet eindelijk een keer aangezwengeld op deze bak wat ook prima werkt (al jaren verschillende AMD cpus gehad, maar nooit de moeite genomen )

Het wordt nog eens wat met het bakkie

Edit: ik liep net nog even te spelen met read_ahead values. /sys/block/sda/queue/read_ahead_kb stond nog op de default 128 waarmee ik zo rond de 170MB/s uitkwam met hdparm -t. Ik heb de value veranderd naar 8192 en performance gaat omhoog naar 216MB/s.
Kijken wat er nog meer verbeterd kan worden...

[ Voor 18% gewijzigd door Theimon op 11-07-2011 09:21 ]

[Verwijderd]

Cool topic!

Ik ga ook een ssd in mijn Ubuntu 10.10 machine smakken...en neem daarvoor een Kingston V+100 96GB met Garbage Collector ingebouwd. Dit model heb ik onlangs in mijn Mac geplaatst en bevalt uitstekend.

fstab aanpassen vwb de noatime, alle andere overbodige hungry disk I/O services (rsync, syslog, udev) uitknallen en gaan met die banaan! Wie heeft zijn disk scheduler trouwens op [noop] staan ipv [cfq]?

[Mentalist]

Verwijderd schreef op maandag 18 juli 2011 @ 17:46:
Cool topic!

Ik ga ook een ssd in mijn Ubuntu 10.10 machine smakken...en neem daarvoor een Kingston V+100 96GB met Garbage Collector ingebouwd. Dit model heb ik onlangs in mijn Mac geplaatst en bevalt uitstekend.

fstab aanpassen vwb de noatime, alle andere overbodige hungry disk I/O services (rsync, syslog, udev) uitknallen en gaan met die banaan! Wie heeft zijn disk scheduler trouwens op [noop] staan ipv [cfq]?

Ik gebruik deadline.

[Verwijderd]

/edit

[ Voor 98% gewijzigd door Verwijderd op 19-07-2011 00:08 ]

[Theimon]

Hier ook de deadline scheduler.

[Verwijderd]

Ik heb eerst de ssd met Gparted geformatteerd op ext.4 als één grote partitie (kwam uit een andere machine) en daarna de installer gedraaid van Ubuntu zelf, deze heeft hem opnieuw ingericht.
Installatie voltooid, lekker snappy allemaal daarna met opstarten etc., maar toen ik een bench draaide in Disk Utility zag ik dit:



Behoorlijk veel pieken omlaag. Is dit normaal? Yep.

Uitlijning/alignment is gewoon normaal. Zowel het OS als de ssd zelf werken met 512K blocks, dus prima 1:1 communicatie. The erase block size is niet van toepassing, omdat de controller zelf 1024K erase blocks wegschrijft en wacht op 2x512K of bij <1024K gewoon 1 block neemt.

Bij het wijzigen van de heads en sectors met fdisk, treedt er zelfs een performance drop op, dus bij gebruik van een Kingston V+100 en Ubuntu 10.10, gewoon zo laten en de auto-installer gebruiken, dan gaat het goed.
Ik kwam er ook gelijk achter dat bij het wijzigen van je partitietabel met fdisk, je dan eerst even de MBR moet wissen (zelf), alvorens je weer kunt installeren met de installer, aan het einde vd installatie kwam ik op de mededeling dat de bootloader niet geïnstalleerd kon worden, waarschijnlijk omdat de installer er vanuit gaat dat deze gewoon blanco is/op een hdd installeert

Terminal: $sudo dd if=/dev/zero of=/dev/sda bs=512 count=1 (voor of tijdens de install) lost dit kleinigheidje op.

[ Voor 70% gewijzigd door Verwijderd op 04-08-2011 23:20 ]

[AlterMann]

Theimon schreef op maandag 11 juli 2011 @ 09:07:
Edit: ik liep net nog even te spelen met read_ahead values. /sys/block/sda/queue/read_ahead_kb stond nog op de default 128 waarmee ik zo rond de 170MB/s uitkwam met hdparm -t. Ik heb de value veranderd naar 8192 en performance gaat omhoog naar 216MB/s.
Kijken wat er nog meer verbeterd kan worden...

Held!

# cat /sys/block/sda/queue/read_ahead_kb
128
$ sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 5606 MB in 2.00 seconds = 2804.69 MB/sec
Timing buffered disk reads: 532 MB in 3.00 seconds = 177.22 MB/sec

# cat /sys/block/sda/queue/read_ahead_kb
8192
$ sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 5930 MB in 2.00 seconds = 2965.95 MB/sec
Timing buffered disk reads: 696 MB in 3.00 seconds = 231.85 MB/sec

[Verwijderd]

read_ahead is dacht ik het cachen van bestanden (in je RAM) zodat de leestijd verkort kan worden, dus mede afhankelijk van andere systeemfactoren, wel mooi natuurlijk dat je performance weer toegenomen is- maar of het helemaal 100% ssd-native is, dat vraag ik mij af. _{boeit verder ook niet, het gaat om het resultaat natuurlijk...}

[CAPSLOCK2000]

Kijk ook eens naar /sys/block/sda/queue/read_ahead_nr, die is misschien nog wel interessanter voor SSD's.

[Verwijderd]

Hallo heb net nieuwe computer met Ubuntu 11.10 en heb er een SSD in zitten en een HDD
wil graag hebben dat de mappen
/home
/var
/usr
/opt
/tmp
naar de HDD verhuizen zodat de SSD leeg is op het besturingssysteem na
kan iemand mij uitleggen hoe ik te werk moet gaan of een site laten zien waar het staat?
ben 2 dagen aan het zoeken geweest en de meeste mensen weten het al en vragen om iets anders
waardoor ik het nog niet weet:)
alvast bedankt

[Intru]

Verwijderd schreef op donderdag 20 oktober 2011 @ 11:08:
Hallo heb net nieuwe computer met Ubuntu 11.10 en heb er een SSD in zitten en een HDD
wil graag hebben dat de mappen
/home
/var
/usr
/opt
/tmp
naar de HDD verhuizen zodat de SSD leeg is op het besturingssysteem na
kan iemand mij uitleggen hoe ik te werk moet gaan of een site laten zien waar het staat?
ben 2 dagen aan het zoeken geweest en de meeste mensen weten het al en vragen om iets anders
waardoor ik het nog niet weet:)
alvast bedankt

Je zou natuurlijk 5 partities kunnen aanmaken voor deze mappen, en ieder op de juiste locatie mounten. Maar ik denk dat je zoiets niet echt voor ogen had. Je kan ook 1 grote partitie maken, die ergens mounten, de 5 dirs erin maken, en die dan vanaf de juiste plek symlinken.

[Verwijderd]

Intru schreef op donderdag 20 oktober 2011 @ 13:17:
[...]


Je zou natuurlijk 5 partities kunnen aanmaken voor deze mappen, en ieder op de juiste locatie mounten. Maar ik denk dat je zoiets niet echt voor ogen had. Je kan ook 1 grote partitie maken, die ergens mounten, de 5 dirs erin maken, en die dan vanaf de juiste plek symlinken.

Ehm... een partie heb ik al van de HDD maar wat is symlinken? en je bedoelt dat ik gewoon die mappen dar heen kan kopieren en die andere kan verwijderen die in de SSD zitten?
betere vraag misschien
hoe kan ik dat alles doen? moet dat in de terminal?

[ Voor 6% gewijzigd door Verwijderd op 20-10-2011 14:34 . Reden: weet niet hoe:s ]

[HTT-Thalan]

Ik heb het hele topic niet doorgelezen, maar wel naar aanleiding van de topictitel wat spitwerk gedaan naar half-SSD drives, te weten de XT Hybrid van Seagate, welke ik in mijn notebook heb hangen.

http://forums.seagate.com...e-files-Linux/td-p/109008

Dit topic vertelt het meeste wat je moet weten, bottom-line is dat je eerst een firmware update naar 2.6 nodig hebt op je XT schijf voor je met een gerust hart een Linux kernel kunt installeren. Ze hebben (nog) niet kunnen bevestigen of de corruptieproblemen zich ook voordoen op windows installaties.

[Intru]

Verwijderd schreef op donderdag 20 oktober 2011 @ 13:55:
Ehm... een partie heb ik al van de HDD maar wat is symlinken? en je bedoelt dat ik gewoon die mappen dar heen kan kopieren en die andere kan verwijderen die in de SSD zitten?
betere vraag misschien
hoe kan ik dat alles doen? moet dat in de terminal?:s

Een symlink is een bestandje dat verwijst naar een andere bestand of map. Zo kan je bv /home laten verwijzen naar /mnt/sdb1/home.

Om dit allemaal uit te voeren is het inderdaad handig om de terminal te gebruiken (voor sommige stappen). Je zal ongeveer het volgende moeten doen:

• Zorg ervoor dat je HDD wordt geautomount (bv op /mnt/sdb1) (hiervoor moet je je fstab aanpassen)
• Verplaats de mappen home/var/usr/opt/tmp van je SSD naar je HDD
• Maak symlinks, hier zijn vast ook wel GUI tools. Maar met de commandline gaat het net zo makkelijk:

  ln -s /mnt/sdb1/home /home

• Klaar!

[Verwijderd]

dus die /mnt/sdb1 staat voor /home? en die terminal regel is hoe je iets mount toch?
ik heb dus nu dit gedaan
sudo ln -s /mnt/sdb1/home /home
sudo ln -s /mnt/sdb2/var /var
en zo verder met rest is dat goed? ik heb de mappen ook gekopieert naar de HDD en kan ik nu de mappen van de SSD halen is dat nu zo goed?

[Intru]

Verwijderd schreef op donderdag 20 oktober 2011 @ 16:56:
dus die /mnt/sdb1 staat voor /home? en die terminal regel is hoe je iets mount toch?
ik heb dus nu dit gedaan
sudo ln -s /mnt/sdb1/home /home
sudo ln -s /mnt/sdb2/var /var
en zo verder met rest is dat goed? ik heb de mappen ook gekopieert naar de HDD en kan ik nu de mappen van de SSD halen is dat nu zo goed?

/mnt/sdb1 is de plek waar je HDD gemount is, waarbij ik er van even vanuit ga dat die HHDD /dev/sdb1 is. Als hij een andere naam heeft onder /dev, dan zou ik hem diezelfde naam geven onder /mnt. Die terminal regel uit mijn vorige post is hoe je een symlink maakt, niet hoe je iets mount. De 2 commandline regels die je post verwijzen beide naar een ander mountpoint (sdb1 en sdb2), weet je zeker dat dit klopt? Dat zou betekenen dat gaat om 2 verschillende partities op je HDD. Ik zou trouwens eerst alles even goed testen voordat je de mappen verwijdert van je SSD, dat lijkt me wel zo handig

[I386DX]

Voor die functionaliteit maak ik gebruik van Binds (kan niet echt het verschil zeggen met symlinks), maar het werkt wel.
Mijn Home-map laat ik overigens op mijn SSD staan (configfiles / cache van de browser staat daar en dat heb ik ook graag snel) met uitzondering van een paar grote directories

Ter voorbeeld; deze lijntjes staan in mijn fstab-bestand

code:

/media/Data/wine/         /home/i386dx/.wine/           bind    defaults,bind 0 0
/media/Data/Downloads/  /home/i386dx/Downloads/     bind    defaults,bind 0 0
/media/Data/Virtualbox  /home/i386dx/.VirtualBox       bind      defaults,bind 0 0

/media/Data is een gewone harde schijf, daarop zijn de directories wine, downloads en virtualbox aangemaakt. Deze worden dan 'gebind' aan de directories op mijn ssd in mijn home-dir.

[Verwijderd]

ah me broer heeft het nu bijna opgelost alleen dan zonder symlinks want hij zegt dat sommige programma's door symlinks niet kunne worden doorgestuurd

[Intru]

I386DX schreef op donderdag 20 oktober 2011 @ 19:44:
Voor die functionaliteit maak ik gebruik van Binds (kan niet echt het verschil zeggen met symlinks), maar het werkt wel.

Goed punt. Gebruik maken van een mount met bind is in dit geval misschien nog wel beter. Een symlink is een inode die doorverwijst (een soort redirect dus), terwijl mounten met bind een echte mount is.

[Verwijderd]

en dat word dan niet geoverwrite dat ter laste is van de SSD?

[Verwijderd]

Ik heb vandaag een Crucial M4 (64GB) gekocht, maar ik kan nergens vinden hoe ik deze nu moet alignen.. Iemand een idee?

En maakt het nog uit hoe ik het filesystem aanmaak (ext4)?

Output van fdisk:

code:

Disk /dev/sdb: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[ Voor 65% gewijzigd door Verwijderd op 27-10-2011 18:31 ]

[DeadLock]

Je hebt geen vermelding gemaakt van een distro, dus ik ga ervanuit dat je het handmatig wenst te doen. Toevallig heb ik vorige week ook een m4 gekocht van 64gb en zit de procedure nog redelijk vers in het hoofd .

Ik heb 'gdisk' gebruikt om de ssd te partitioneren. Nadat je gdisk start voor de correcte disk (sdb dus) kan je best even een nieuwe partitietabel generen met 'o' om te kiezen voor gpt. Vervolgens gebruik maken van 'n' om partities aan te maken. Gdisk zal er automatisch voor kiezen om op sector 2048 te starten, wat ervoor zorgt dat de allignment goed zit.

Mijn partitietabel ziet er als volgt uit:

code:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            6143   2.0 MiB     EF02  BIOS boot partition
   2            6144        37754879   18.0 GiB    8300  Linux filesystem
   3        37754880       121640959   40.0 GiB    8300  Linux filesystem

Zoals je kan zien heb ik een kleine (2MiB) bios boot partite, dit om met grub2 te kunnen booten vanaf een GPT partitietabel. Met de oude legacy grub1 (0.97) kan je niet booten vanaf een gpt disk. Grub2 is net wat anders wat betreft configuratie dan de oude grub, in het kort komt het hierop neer:

Grub2 installeren:

code:

grub_bios-install --boot-directory=/boot --no-floppy --recheck /dev/sdb

Nadien moeten we een grub.cfg generenen:

code:

grub-mkconfig -o /boot/grub/grub.cfg

Daarbuiten heb ik /tmp in ram staan en natuurlijk mounten met de optie 'discard' om trim te activeren.

Dit is hoe ik het gedaan heb, ymmv. Tevens gaat dit uit van een ouderwets bios, met uefi moet het net wat anders.

[Verwijderd]

Bedankt voor de info!

Ik draai Gentoo, inmiddels had ik hem al met fdisk gepartitioneerd. Hij begint bij mij ook op sector 2048 dus dat zal dan wel goed zitten.

Heb overigens gewoon de grub 0.97 gebruikt.

[DeadLock]

Ik denk dat je alingment dan mogelijk niet goed zit, kan je even een fdisk output posten zodat iemand (met meer kennis dan ik) er even naar kan kijken?

Zie ook deze post op het ocz forum. Ik heb geen idee of je gebruik gemaakt hebt van de optie om te kiezen voor 32 heads en 32 sectors zodat je cylinders krijgt van 512KB?

[ Voor 12% gewijzigd door DeadLock op 27-10-2011 22:35 ]

[Verwijderd]

Ik heb wel gekozen voor -H 32 en -S 32 ja, al lijkt het er hieronder anders uit te zien.

code:

Disk /dev/sdb: 64.0 GB, 64023257088 bytes
22 heads, 16 sectors/track, 355242 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   125045423    62521688   83  Linux

Als ik een read benchmark doe via disk utility haal ik 560MB/s gemiddeld.

Na een reboot lijkt het of er niks met de sysctl.conf word gedaan. Meerdere mensen met dit probleem?

[ Voor 12% gewijzigd door Verwijderd op 28-10-2011 19:00 ]

[B2]

Wat zijn jullie tips voor het alignen van een Intel 320 80GB? De SSD wordt met name ingezet voor de hypervisor en de vm's die er op komen te draaien. Alle log files van zowel de Hypervisor als de VM's gaan naar een standaard HDD.

Ik draai Scientific Linux 6.1.

[ Voor 6% gewijzigd door B2 op 23-11-2011 22:04 ]

[BlueMotion]

Ik heb een arch linux installatie met een cricual m4 (OS) en een hdd(grote data). Nu probeer ik via fstab alle ext4 partities te mounten met de discard optie.

de output van "mount -l" geeft aan dat discard wel geactiveerd is op de partitie op de hdd, maar niet bij de partities op de ssd. Weet iemand hoe dat dat kan en wat ik daaraan kan doen?

De M4 is trouwens voorzien van de nieuwste firmware.

[_JGC_]

Hoe heb je die SSD aangesloten? Toch wel op een AHCI controller? Hier staat er gewoon "discard" in de mount opties op mijn Intel X25-M onder Archlinux.

[BlueMotion]

Mijn SATA controller staat in AHCI-mode, de hdd is er (volgens mij) ook op aangesloten en die doet het wel. Ik heb voor de zekerheid nog even de andere SATAIII poort geprobeerd: zelfde probleem.

Edit: Oja, mijn moederbord is een intel DH67BL.

[ Voor 26% gewijzigd door BlueMotion op 02-02-2012 09:40 ]

[Tim]

Bij mij verschijnt discard ook niet in de mount-opties, maar het werkt wel gewoon. Nu heb ik de discard als default opgegeven met tune2fs ipv via fstab (dat is te controleren met tune2fs -l /dev/xxx).
Heb je verder nog mount opties? Zo kwam ik er ook achter dat data=writeback niet werkt met trim.

Hier is een manier om zeker te zijn of trim werkt: http://andyduffell.com/techblog/?p=852

edit: Overigens is discard op niet-ssd schijven waarschijnlijk geen goed idee.

[ Voor 9% gewijzigd door Tim op 02-02-2012 11:46 ]

[BlueMotion]

Oke, die test werkt bij mij

$ mount -l
geeft nog steeds niets weer. Ik ben even aan het zoeken geweest in de output van
$ dmesg
Daarin staat de discard option wel:

mounted filesystem(...) Opts: discard

Ik heb overigens default,noatime als verdere mount opties bij de ssd. En de default voor data=ordered.

Waarom zou discard voor niet SSD's niet zo'n goed idee zijn? Ik meende ergens gelezen te hebben dat dat ook prima kon, maar dat kan ik zo even niet weervinden..

[Mentalist]

BlueMotion schreef op donderdag 02 februari 2012 @ 14:36:
Waarom zou discard voor niet SSD's niet zo'n goed idee zijn? Ik meende ergens gelezen te hebben dat dat ook prima kon, maar dat kan ik zo even niet weervinden..

Op harde schijven lijkt het me iig niet zinvol (geen performancewinst), tenzij je datarecovery wilt frustreren.

Komt bij dat omdat niemand het gebruikt er misschien bugs in de firmware van je harde schijf zitten waardoor data corrupt raakt.

[Sando]

Waarom TRIM't ie nu niet?

Ik heb net een SSD in mijn Lenovo Thinkpad Edge gebouwd.

code:

# hdparm -i /dev/sda | grep -i model
 Model=M4-CT256M4SSD2, FwRev=0009

Ik draai Ubuntu 11.10, kernel 3.0.0:

code:

$ uname -a
Linux Redsandro 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

En zonder iets te veranderen staat het sterretje van enabled op enabled:

code:

# hdparm -I /dev/sda | grep -i trim
    (Enabled    Supported:)
       *    Data Set Management TRIM supported (limit 8 blocks)
       *    Deterministic read data after TRIM

Maar als ik ga testen:

code:

$ dd if=/dev/urandom of=temp bs=1M count=3
$ hdparm --fibmap temp
temp:
 filesystem blocksize 4096, begins at LBA nnnnnn; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           m  xxxxxx  yyyyyy        zzz
$ rm temp && sync && sleep 400 && hdparm --read-sector xxxxxx /dev/sda


/dev/sda:
reading sector xxxxxx: succeeded
[allemaal random data]

krijg ik allemaal random data, niet getrimt dus.

Vervolgens voeg ik de optie discard aan fstab toe, ookal is dat volgens mij niet nodig, maar na een reboot staat er nog steeds [allemaal random data], niet getrimt dus.

code:

$ cat /etc/fstab | grep discard
UUID=[removed] /           ext4    discard,noatime,errors=remount-ro     0       1
UUID=[removed] /home       ext4    defaults,discard,noatime              0       2

code:

$ hdparm --read-sector xxxxxx /dev/sda

/dev/sda:
reading sector xxxxxx: succeeded
[allemaal random data]

Uiteindelijk wiper.sh van hdparm voor TRIMloze huilie-SSD's gebruikt:

code:

$ wiper.sh --commit /dev/sda5

wiper.sh: Linux SATA SSD TRIM utility, version 3.3, by Mark Lord.
Preparing for online TRIM of free space on /dev/sda5 (ext4 mounted read-write at /).

This operation could silently destroy your data.  Are you sure (y/N)? y
Creating temporary file (22072791 KB).. 
Syncing disks.. 
Beginning TRIM operations..

[blah blah]

succeeded
Removing temporary file..
Syncing disks.. 
Done.

En dan is de boel wel getrimt:

code:

$ hdparm --read-sector xxxxxx /dev/sda

/dev/sda:
reading sector xxxxxx: succeeded
0000 0000 0000 0000 0000 0000 0000 0000

[Jormungandr]

Zijn er nog mensen waar een hardnekkige SSD en koppige fdisk voor verhoogde bloeddruk zorgt?

Ik ben bezig met het installeren van Arch op mijn Intel 320 120GB SSD en de alignment wil maar niet op -H 32 -S 32 blijven staan.

Ik doe netjes de fdisk -S 32 -H 32 /dev/sda en maak mijn partities aan. Als ik na het aanmaken een 'p' doe, zie ik nog steeds 32h/32s staan. Doe ik een write en daarna een fdisk -l /dev/sda en fdisk -lu /dev/sda, dan staat het weer standaard op 255h, 63s.

Zowel met de Arch installer als de fedora liveCD krijg ik hetzelfde fenomeen.

[Borromini]

De arch installer heeft gdisk, dat werkt een stuk makkelijker met SSD's.

https://wiki.archlinux.org/index.php/Solid_State_Drives

[_JGC_]

Ik zou niet weten waarom je met fdisk en C/H/S instellingen zou kloten als je gewoon met parted een partitie op 1MB kunt starten en vervolgens partitiegroottes in megabytes aangeeft. Als je alignment niet klopt begint parted er zelf ook wel over tegenwoordig.

[Rprp]

Interessant: ik heb nooit problemen gehad met TRIM, maar heb nu een Plextor m3p in een server geinstalleerd en deze doet toch "raar".

Op de Intel X25-M worden de sectors vrijwel instant getrimmed (binnen 2-3 seconden). Ik heb dit al met 5+ servers gedaan, nooit problemen gehad.

Vandaag de Plextor M3P uitgeprobeerd en deze "trimmed" pas na 60-90 seconden. Is dit een "feature" v.d. controller (uitstellen?) of wordt dit niet gedaan door het OS maar door garbage collection en moet ik m'n settings nakijken?

[Sallin]

Ik heb recent linux op een SSD geinstalleerd met een ext4 filesystem en dit ging vrij automatisch. Het enige wat ik heb ingesteld is de discard en noatime optie in /etc/fstab. Op basis van de huidige TS maakte ik me wat zorgen of het niet ingewikkeld zou zijn, maar dat was voor mij niet zo. Verder was de performance volgens mij ook goed voor een 128GB:

hdparm -tT --direct /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   926 MB in  2.00 seconds = 462.67 MB/sec
 Timing O_DIRECT disk reads: 1462 MB in  3.00 seconds = 487.10 MB/sec

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   28688 MB in  2.00 seconds = 14362.14 MB/sec
 Timing buffered disk reads: 1492 MB in  3.00 seconds = 497.17 MB/sec

[Elijan9]

Volgens Linux Ext4 ontwikkelaar Theodore Ts'o is het tegenwoordig beter om geen "discard" mee te geven aan ext4, maar gewoon bijvoorbeeld één keer per week fstrim uit te voeren (bijvoorbeeld als cronjob):

Again, using direct TRIM support from the file system is generally going to be a performance problem for all current SSD's, since the TRIM command is a non-queuable command, so it requires a NCQ queue flush --- and many SSD's have a highly inefficient and slow TRIM command. As a consequence, you don't want to issue a trim on every single journal commit. A much better thing to do is to use fstrim once a day or once a week (which for many SSD's and workloads is plenty).

Bron: https://plus.google.com/1...9033135/posts/BW2PX7eXmqx

[Sando]

Is dat niet gewoon in het systeem geregeld?
Ik heb helemaal niets ingesteld, en bij mij wordt verwijderde data ook gewoon weggeTRIMd.

Het zou ook van de zotte zijn als je anno 2012 je SSD handmatig moet TRIMmen.

Altans, bij een modern FS als EXT4. Als je geen EXT4 hebt ingesteld dan moet je inderdaad handmatig moeilijk doen.

[Verwijderd]

Elijan9 schreef op maandag 24 september 2012 @ 11:49:
Volgens Linux Ext4 ontwikkelaar Theodore Ts'o is het tegenwoordig beter om geen "discard" mee te geven aan ext4, maar gewoon bijvoorbeeld één keer per week fstrim uit te voeren (bijvoorbeeld als cronjob):
[...]
Bron: https://plus.google.com/1...9033135/posts/BW2PX7eXmqx

Moet ik dan hém geloven of moet ik de tutorials geloven die over heel het internet is verspreid...

[Elijan9]

Sando schreef op maandag 24 september 2012 @ 15:35:
Is dat niet gewoon in het systeem geregeld?
Ik heb helemaal niets ingesteld, en bij mij wordt verwijderde data ook gewoon weggeTRIMd.

Als je mount met de optie "discard" dan wordt het "in het systeem geregeld". Echter, dat gaat dus ten koste van performance volgens de hoofdontwikkelaar van ext4 en volgens hem is het dus eigenlijk beter dit eens in de zoveel tijd handmatig te doen met fstrim... Het is dus geen kwestie van "handmatig moeten doen" maar van "handmatig willen doen".

Handmatig TRIM-en is sowieso eigenlijk alleen mogelijk bij moderne filesystemen, een filesysteem moet namelijk met de fysieke laag (de SSD) communiceren welke sectors niet actief gebruikt worden om TRIM (en `fstrim`) te laten werken.

Verwijderd schreef op maandag 24 september 2012 @ 17:14:
Moet ik dan hém geloven of moet ik de tutorials geloven die over heel het internet is verspreid...

Theodore Ts'o lijkt mij dan toch echt de meest betrouwbaardere bron. Iedereen kan een tutorial schrijven, maar niet iedereen is dè Linux hoofdontwikkelaar van de ext2, ext3 en ext4 filesystemen en heeft zoveel te maken gehad met TRIM support in Linux...

[ Voor 23% gewijzigd door Elijan9 op 24-09-2012 17:48 . Reden: reactie bitking ]

[Verwijderd]

Elijan9 schreef op maandag 24 september 2012 @ 17:15:
[...]

Als je mount met de optie "discard" dan wordt het "in het systeem geregeld". Echter, dat gaat dus ten koste van performance volgens de hoofdontwikkelaar van ext4 en volgens hem is het dus eigenlijk beter dit eens in de zoveel tijd handmatig te doen met fstrim... Het is dus geen kwestie van "handmatig moeten doen" maar van "handmatig willen doen".

Handmatig TRIM-en is sowieso eigenlijk alleen mogelijk bij moderne filesystemen, een filesysteem moet namelijk met de fysieke laag (de SSD) communiceren welke sectors niet actief gebruikt worden om TRIM (en `fstrim`) te laten werken.

Zo onhandig, handmatig is niet meer van deze tijd Mijn discard blijft staan hoor! NÉM!

[Sallin]

Ik snap niet helemaal of zijn commentaar nu altijd toepasbaar is of voor de specifieke context van de thread, namelijk dingen compileren.

[Mentalist]

Verwijderd schreef op maandag 24 september 2012 @ 17:26:
[...]

Zo onhandig, handmatig is niet meer van deze tijd Mijn discard blijft staan hoor! NÉM!

Je zou ook kunnen trimmen bij het afsluiten (of opstarten) van de computer in een script, dan hoef je ook niks handmatig te doen.

[Sando]

Elijan9 schreef op maandag 24 september 2012 @ 17:15:
[...]

Als je mount met de optie "discard" dan wordt het "in het systeem geregeld". Echter, dat gaat dus ten koste van performance volgens de hoofdontwikkelaar van ext4 en volgens hem is het dus eigenlijk beter dit eens in de zoveel tijd handmatig te doen met fstrim... Het is dus geen kwestie van "handmatig moeten doen" maar van "handmatig willen doen".

Je uitleg is helder maar het klopt volgens mij niet. Ik heb geen extra mountopties. Geen discard. (Geen noatime, hoewel dat misschien wel een idee is om mijn SSD 1% i/o te ontzien.) En toch wordt het netjes geTRIMt.

Ik zal even voor je opzoeken hoe je dat ookalweer kunt testen..

(to be editted)

edit:

• dd if=/dev/urandom of=random.tmp bs=1M count=4 && sync
• sudo hdparm --fibmap random.tmp
  • blabla ff herhalen totdat je ziet begin_LBA = xxxxxxxx
• sudo hdparm --read-sector xxxxxxxx [url]/dev/sda[/url]
  • 310f 036d 8d5c 504f <- willekeurige data hier
• rm random.tmp && sync
• Paar minuten wachten en opnieuw:
• sleep 150 && sudo hdparm --read-sector xxxxxxxx [url]/dev/sda[/url]
  • 0000 0000 0000 0000 <- als alles 0 is, dan werkt trim goed.

WUT? Op mijn laptop werkt het wel, maar op mijn HTPC werkt het niet? What kind of sourcery is this??

edit:

Oh wacht, mijn HTPC is nogal getweaked, maar ik kan mijn eigen tweaks niet terugvinden.

[ Voor 43% gewijzigd door Sando op 24-09-2012 22:25 ]

[Elijan9]

Sallin schreef op maandag 24 september 2012 @ 18:32:
Ik snap niet helemaal of zijn commentaar nu altijd toepasbaar is of voor de specifieke context van de thread, namelijk dingen compileren.

Het beïnvloedt met name de schrijf-performance en enigszins de lees-performance op het moment dat er tegelijkertijd wordt geschreven. Bij compileren speelt zoiets, maar ook bij rippen, videobewerking, P2P, (applicaties) opstarten. Extra performance op die (paar?) momenten dat je het nodig hebt.

Sando schreef op maandag 24 september 2012 @ 20:53:
Je uitleg is helder maar het klopt volgens mij niet. Ik heb geen extra mountopties. Geen discard. (Geen noatime, hoewel dat misschien wel een idee is om mijn SSD 1% i/o te ontzien.) En toch wordt het netjes geTRIMt.

Geen discard expliciet meegeven via fstab wil niet meteen zeggen dat de optie niet aan staat, een subset van de mogelijke mountopties kun je in het filesysteem zelf instellen, met `tune2fs -o discard ...` of ook via `tune2fs -E mount_opts=discard ...` Volgens de mount manpage staat discard in elk geval standaard uit, maar het kan zijn dat Linux distributies deze default veranderd hebben in hun kernels:

This is useful for SSD devices and sparse/thinly-provisioned LUNs, but it is off by default until sufficient testing has been done.

[ Voor 23% gewijzigd door Elijan9 op 25-09-2012 10:39 ]

[Sando]

Of misschien heb ik het dan toch ooit eens zelf geactiveerd op de laptop. Bedankt voor het attenderen in ieder geval.

Heb maar even snel mijn EXT4's van discard optie voorzien
$ sudo tune2fs -o discard /dev/sda1
$ sudo tune2fs -o discard /dev/sda3

Want blijkbaar stond alles constant vol. Gelukkig leeft de SSD nog. (Ik heb ook geen idee hoe zo'n vaart dat loopt zonder TRIM)

Ik weet dat je juist probeert uit te leggen dat we beter niet discard kunnen gebruiken, maar dit is mijn HTPC, performance boeit niet zoveel. Ik kan altijd nog even CRON erbij halen, maar op mijn laptop heb ik me nooit echt ge-ergerd aan TRIMs wanneer het niet uitkomt ofzo.

Ik vind het wel van de ratten dat het niet standaard werkt bij een SSD, zoals op alle andere systemen in de rest van het heelal.

[ Voor 56% gewijzigd door Sando op 25-09-2012 15:34 ]

[Elijan9]

Sando schreef op dinsdag 25 september 2012 @ 15:26:
...

Want blijkbaar stond alles constant vol. Gelukkig leeft de SSD nog. (Ik heb ook geen idee hoe zo'n vaart dat loopt zonder TRIM)

Een SSD gaat er niet meteen dood van, alleen kan de SSD veel efficiënter nieuwe data wegschrijven als het weet welke blokken ongebruikt zijn.
Mounten met "discard" lost het volgens mij alleen op voor nieuwe schrijfbewerkingen, ik vermoedt dat je alsnog even fstrim moet draaien. Als je fstrim met "-v" draait zie je meteen hoeveel data er getrimmed is...

Ik vind het wel van de ratten dat het niet standaard werkt bij een SSD, zoals op alle andere systemen in de rest van het heelal.

Onder Windows werkt het ook pas vanaf versie 7, en voor Mac OSX vanaf 10.6.8. "Alle andere systemen in de rest van het heelal" valt dus ernstig mee, in elk geval op en rond de aardbol draait zeker de helft een systeem zonder TRIM support. Windows 7 schakelt TRIM trouwens pas (handmatig) in als je de "Prestatie Index" bijwerkt, op een manier die vergelijkbaar is met `tune2fs -odiscard ...`
Eerlijk gezegd vind ik het ook niet helemaal terecht dat discard nog steeds niet standaard aan staat, maar ik heb al meerdere malen meegemaakt dat het opstarten van Linux 2 seconden bijna stil staat op het moment dat een swapfile met "discard" werd gemount (op een inmiddels overleden OCZ Vertex 2), dus het kan behoorlijk vertragen...

[Sando]

Elijan9 schreef op woensdag 26 september 2012 @ 10:42:
Als je fstrim met "-v" draait zie je meteen hoeveel data er getrimmed is...

Onder Windows werkt het ook pas vanaf versie 7, en voor Mac OSX vanaf 10.6.8. "Alle andere systemen in de rest van het heelal" valt dus ernstig mee

Ja dat weet ik ook wel, maar Linux is altijd zo snel met nieuwe dingen, dagelijks 10tallen patches enzo.
Windows 7 komt overigens uit 2009, en de reden dat OSX pas TRIM ondersteunt vanaf 2011 is omdat ze daarvoor (2008?) al Apple-SSD's verkochten welke dit op een andere manier deden, iirc, hardwarematig zonder dat het OS daar over ging, wat performancetechnisch onder deed voor TRIMcommando's vanuit het systeem.

Linux loopt wel degelijk 3 jaar achter door bepaalde systeemfunctionaliteit-verantwoordelijkheden bij de gebruiker te laten liggen in plaats van ze door het systeem - daar is het immers voor - te laten regelen.

Dat sommige mensen nog XP draaien, ja daar heb ik dan wat minder een boodschap aan. Oude software en nieuwe technologie gaat logischerwijs niet altijd samen.

al meerdere malen meegemaakt dat het opstarten van Linux 2 seconden bijna stil staat op het moment dat een swapfile met "discard" werd gemount (op een inmiddels overleden OCZ Vertex 2), dus het kan behoorlijk vertragen...

Je moet je swap toch ook gewoon als swap mounten? En alle rommel gewoon (encrypted) laten staan. Swap ondersteunt geen TRIM, alleen EXT4 doet dat.

[Ultraman]

Ik denk dat "swapfile" het essentiële uit zijn verhaal is. Namelijk geen losse swap partitie, maar een file dus, en die kan best op een ext4 filesystem staan.

[ Voor 17% gewijzigd door Ultraman op 26-09-2012 20:20 ]

[Elijan9]

Sando schreef op woensdag 26 september 2012 @ 18:54:
...
Swap ondersteunt geen TRIM, alleen EXT4 doet dat.

code:

swapon --discard /dev/....

En nee, volgens mij is het beter data die je niet nodig hebt z.s.m. terug te geven aan de SSD controller via TRIM, ook oude swap data... (TRIM is juist bedoeld om geen rommel te laten staan.)

Volgens de Linux 3.5 sources zit er ook discard ondersteuning in vfat en gfs2(?), naast xfs, nilfs, btrfs, ext2 en ext3. vfat heb ik meteen getest en dat werkt inderdaad...

[ Voor 31% gewijzigd door Elijan9 op 26-09-2012 23:56 ]

[Trax_Digitizer]

Ik ben van plan om een nieuwe Linux server aan te schaffen (tbv hosting doeleinden en router@home). Mijn huidige server (een oude P4 met SATA1) is dusdanig oud dat het tijd wordt om over te stappen op een nieuw platform. Een upgrade is niet meer aan de orde. In mijn nieuwe server wil ik gebruik gaan maken van SSD('s).

In dit topic heb ik al een aantal goede tips gevonden die ik zeker ga toepassen. Zo ga ik mijn squid cache en /tmp in het RAM zetten en ga ik geen swap partitie meer gebruiken. Met 8 GB RAM moet dit makkelijk lukken. Draai geen X en doe alles in de shell. Het punt waar ik over twijfel is het toepassen van SW RAID 1 met twee SSD's (Crucial m4 128 GB).

In mijn huidige server gebruik ik SW RAID 1 (t.b.v. continuiteit) al jaren icm reguliere harddisks en dat bevalt prima. Via Google kom ik echter uit bij personen die het gebruik van SW RAID 1 i.c.m. SSD's afraden. Dit omdat Linux SW RAID nog niet goed omgaat met het TRIM commando. Dit zou nadelig uitpakken voor de performance en levensduur van de SSD. Ik lees daarentegen ook weer stukken van mensen die het wél met succes hebben toegepast. Op dit moment weet ik dus even niet meer wat "waar" is. Doordat ik de feiten niet goed ken, vind ik het lastig om keuzes te maken.

De reden dat ik überhaupt SSD's wil gebruiken (t.o.v. reguliere harddisks) is in de eerste plaats het geluidsniveau. Ik weet mijn server redelijk stil te krijgen, maar de harddisks maken op dit moment het meeste lawaai. Dat komt ook doordat mijn huidige consumenten harddisks al 6 jaar 24x7 draaien in RAID 1; de lagers slijten waardoor het lawaai toeneemt. Dat is wel een situatie waar ik in de toekomst vanaf wil. Daarnaast is de snelheidswinst van een SSD t.o.v. een HD natuurlijk mooi mee genomen. Met name bij het inladen van grote mailboxen via de webmail verwacht ik hier snelheidswinst. Bij 5000 mails kost dat wel wat laadtijd op dit moment.

De totale hoeveelheid data op mijn huidige server is ongeveer 30 GB. Dat is dus inclusief OS, software en gebruikersdata.

Kortom, wat is verstandig? Ga ik voor 1x SSD of ga ik voor 2x SSD in RAID 1? Iemand ervaring met een soortgelijk vraagstuk?

[Elijan9]

Trax_Digitizer schreef op maandag 17 december 2012 @ 09:27:
[...]
In mijn huidige server gebruik ik SW RAID 1 (t.b.v. continuiteit) al jaren icm reguliere harddisks en dat bevalt prima. Via Google kom ik echter uit bij personen die het gebruik van SW RAID 1 i.c.m. SSD's afraden. Dit omdat Linux SW RAID nog niet goed omgaat met het TRIM commando.

Linux kernel 3.7 is recentelijk uitgebracht en deze ondersteunt nu wel TRIM in combinatie met SW RAID, zie:
http://kernelnewbies.org/...6e69ed24f88e0eb83217fa8df Eerdere kernels ondersteunden TRIM voor zover ik weet helemaal niet i.c.m. software RAID.

[AlterEgo]

Trax_Digitizer schreef op maandag 17 december 2012 @ 09:27:

Is een periodiek fstrim-commando geen redelijk alternatief?

[Sando]

Elijan9 schreef op woensdag 26 september 2012 @ 21:33:
[...]

code:

swapon --discard /dev/....

Huw? Wist ik niet Enig idee hoe dat werkt met cryptoswap in fstab wat Ubuntu en consorten volgens mij standaard gebruiken?

[Mentalist]

Trax_Digitizer schreef op maandag 17 december 2012 @ 09:27:
In dit topic heb ik al een aantal goede tips gevonden die ik zeker ga toepassen. Zo ga ik mijn squid cache en /tmp in het RAM zetten en ga ik geen swap partitie meer gebruiken. Met 8 GB RAM moet dit makkelijk lukken. Draai geen X en doe alles in de shell. Het punt waar ik over twijfel is het toepassen van SW RAID 1 met twee SSD's (Crucial m4 128 GB).

Niet doen. Als je een goede SSD hebt (zoals een Crucial M4 of Samsung 830, koop nooit Sandforcetroep) dan is een defect sowieso al behoorlijk onwaarschijnlijk. Mocht er toch iets mis gaan, dan is de kans vrij groot dat beide SSD's tegelijk kapot gaan:

• Slijtage, bijvoorbeeld door een intensieve database te draaien, zal beide SSD's op ongeveer hetzelfde moment laten falen.
• Crucial 5000 uur bug, geeft geen dataverlies maar de computer loopt wel steeds vast na een uur. Logischerwijs zullen beide SSD's in RAID1 hier op vrijwel precies hetzelfde moment tegenaan lopen als je firmware niet up-to-date is.

SSD's zijn anders dan harde schijven die door hun mechanische aard op een meer willekeurig moment de fout in konden gaan. RAID1 bij SSD's is imho niet zinvol.

[Elijan9]

Sando schreef op maandag 17 december 2012 @ 15:54:
[...]

Huw? Wist ik niet Enig idee hoe dat werkt met cryptoswap in fstab wat Ubuntu en consorten volgens mij standaard gebruiken?

Bij Ubuntu weet men het ook nog niet, Ubuntu gebruikt de eigen tool "mountall" om alles in fstab af te handelen en deze ondersteunt (nog) geen discard optie bij swap (wordt genegeerd), dat zal voor cryptoswap niet anders zijn. Ik heb daar al een patch voor klaar liggen, maar moet nog even de tijd vinden om dit te melden.

Met cryptoswap heb ik geen ervaring, maar ik denk dat bij cryptoswap de swapfile ook opnieuw geïnitialiseerd moet worden en dan zou discard meteen een schone lei opleveren, dus het zou zeker nuttig en logisch zijn om discard ook hier te gebruiken/ondersteunen...

[_JGC_]

W3ird_N3rd schreef op maandag 17 december 2012 @ 23:23:
[...]

Niet doen. Als je een goede SSD hebt (zoals een Crucial M4 of Samsung 830, koop nooit Sandforcetroep) dan is een defect sowieso al behoorlijk onwaarschijnlijk. Mocht er toch iets mis gaan, dan is de kans vrij groot dat beide SSD's tegelijk kapot gaan:

• Slijtage, bijvoorbeeld door een intensieve database te draaien, zal beide SSD's op ongeveer hetzelfde moment laten falen.
• Crucial 5000 uur bug, geeft geen dataverlies maar de computer loopt wel steeds vast na een uur. Logischerwijs zullen beide SSD's in RAID1 hier op vrijwel precies hetzelfde moment tegenaan lopen als je firmware niet up-to-date is.

SSD's zijn anders dan harde schijven die door hun mechanische aard op een meer willekeurig moment de fout in konden gaan. RAID1 bij SSD's is imho niet zinvol.

Bij RAID1 heb je idd het probleem dat 2 identieke SSDs op hetzelfde moment door hun writes heen zijn. Ik heb een 6-tal Crucial M4s in RAID6 hangen in een databaseserver, daarvan zijn er een aantal op 4% levensduur, een aantal op 9% en een aantal zitten al op 13%. Dat is een server met 300GB aan databases die de hele dag staat te schrijven (wel met 512MB WB cache en BBU). Al met al zijn die SSDs over een jaar of 7-8 gewoon op, maar voor die tijd gok ik dat er vraag is naar een grotere server met meer cores, meer geheugen en ook weer nieuwe opslag.

Heb bij die server vooral in het begin last gehad van uitvallende SSDs door firmware bugs. Uiteindelijk de interface geforceerd naar 3Gbit/s, maar sinds 000F kan die gewoon weer naar 6Gbit/s. Latere firmwares heb ik nog niet geflasht, zie de noodzaak niet echt.

Edit:
Naast de willekeur van RAID6 met 256KB stripesize komt het verschil in levensduur ook door het feit dat het array een aantal keren in degraded mode heeft gedraaid omdat een SSD zich door firmwarebugs ineens ging afmelden bij de controller en pas bij de volgende powercycle weer gevonden werd.

[ Voor 7% gewijzigd door _JGC_ op 19-12-2012 12:14 ]

[Trax_Digitizer]

Bedankt voor de reacties. De nieuwe server met 2x crucial m4 128GB draait inmiddels, maar nog zonder raid 1. Sterker nog, 1 SSD is momenteel helemaal niet aangesloten. Ik installeer het systeem eerst volledig op 1 SSD en besluit dan later nog of ik de 2e SSD voor raid 1 wil gebruiken. Ik kan hem ook 'bewaren' voor als mijn huidige SSD versleten is. Weet nog niet wat verstandig is. Als de kans groot is dat ze beiden tegelijk falen, dan heeft raid 1 niet zoveel nut. Maar als ik de andere SSD bijvoorbeeld na een jaar pas aansluit, dan is de kans dat ze tegelijk falen alweer een stuk kleiner.

Ik vraag me overigens af of mijn SSD nu goed 'gealigned' is. Zie hieronder de output van 'fdisk -lu'

code:

Disk /dev/sda: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0007eb5f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   250068991   125033472   83  Linux

Hier las ik dat je dan de startsector * 512 / 4096 moet doen. En als daar dan een rond getal uitkomt, dan zou de SSD goed gealigned zijn. In mijn geval is dat een geheel getal, maar ik begrijp niet goed waarom dit dan klopt. Is dit niet afhankelijk van de "clustergrootte"? En moet dit voor mijn SSD niet 4096 bytes zijn ipv de 'oude' 512 bytes?

[Mentalist]

Trax_Digitizer schreef op zaterdag 22 december 2012 @ 16:33:
Bedankt voor de reacties. De nieuwe server met 2x crucial m4 128GB draait inmiddels, maar nog zonder raid 1. Sterker nog, 1 SSD is momenteel helemaal niet aangesloten. Ik installeer het systeem eerst volledig op 1 SSD en besluit dan later nog of ik de 2e SSD voor raid 1 wil gebruiken.

Ik zei het al, maar RAID1 is niet bijster zinnig in deze setup. Als je iets wil doen, zorg dan gewoon voor dagelijkse backups, of zelfs backups ieder uur afhankelijk van wat erop staat.

RAID1 is geen backup.

Ik kan hem ook 'bewaren' voor als mijn huidige SSD versleten is. Weet nog niet wat verstandig is.

Dat is niet verstandig, want afhankelijk van wat je ermee doet kan het zomaar 10 jaar duren eer hij versleten is. Tegen die tijd koop je een veel betere SSD voor dat geld.

[Trax_Digitizer]

RAID 1 gebruik ik alleen tegen het falen van een schijf waardoor ik niet meteen een systemrestore hoef te doen. Backups maak ik elke week met rsync naar mijn NAS. Wellicht dat ik de SSD dan toch voor mijn 13" laptopje kan gebruiken. Daar zit nu zo'n trage 4200 toerenschijf in en die heb ik al eens willen vervangen.

[Mentalist]

Lijkt me idd een beter idee.

Een flexibeler idee om aan te denken zou zijn om het gehele systeem bijvoorbeeld wekelijks te backuppen. In het onwaarschijnlijke geval dat de SSD zou falen steek je die 4200rpm schijf uit je laptop erin en zet je daar de laatste backup van het systeem op terug.

Persoonlijk zou ik gewoon de boel de boel laten: de moeite om een systeem backup te maken (of de kosten van een RAID1) wegen niet op tegen de kans op een minor inconvenience van het opnieuw instellen van je systeem in het geval de SSD zou falen.

[ Voor 29% gewijzigd door Mentalist op 22-12-2012 18:55 ]

[Trax_Digitizer]

Omdat ik /var/log/ ook in het RAM (tmpfs) heb gezet, zoek ik een manier om de inhoud te behouden bij een reboot. De basale gedachte is dat ik de inhoud van /var/log/ mbv tar naar mijn SSD wegschrijf bij een shutdown, de inhoud weer terugzet bij het booten.

Ik heb me zitten verdiepen in bootscripts en ben met een bestaand script in /etc/init.d/ en de informatie op een aantal websites (1, 2) aan de slag gegaan. Zie hieronder het resultaat van mijn "log_maintainer" bootscript.

code:

#!/bin/sh

### BEGIN INIT INFO
# Provides:          log_maintainer
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 1 6
# Short-Description: restore logfiles in tmpfs
### END INIT INFO

# on shutdown, before unmout tmpfs: /bin/tar zpcvf /root/var_log.tar.gz /var/log/* > /dev/null
# on boot, after mount tmpfs: /bin/tar zpxvf /root/var_log.tar.gz -C / > /dev/null

PATH=/sbin:/usr/sbin:/bin:/usr/bin

do_start() {
        echo -n "Restoring logfiles (/var/log/) from disk to RAM (tmpfs)..."
        /bin/tar zpxvf /root/var_log.tar.gz -C / > /dev/null
        echo "done."
}

do_stop() {
        echo -n "Writing logfiles (/var/log/) from RAM (tmpfs) to disk..."
        /bin/tar zpcvf /root/var_log.tar.gz /var/log/* > /dev/nul
        echo "done."
}

case "$1" in
    start)
        do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        do_stop
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

Vervolgens heb ik via sysv-rc-conf de juiste symlink in /etc/rcS.d/ aangemaakt. Ik heb hier heel bewust voor runlevel "S" gekozen, omdat ik dit /var/log/ gevuld wil hebben voordat de applicaties worden gestart die hier gebruik van maken (rsyslog, apache2, squid3, postfix, courier, etc...), maar pas nadat alles in /etc/fstab (zie hieronder) is gemount.

code:

tmpfs   /var/log        tmpfs   defaults,noatime,mode=0755      0       0

Ik heb het getest met een reboot, maar er gebeurt helemaal niks. En ja het script is executable (-rwxr-xr-x root root).

Toen heb ik het nog geprobeerd in runlevel 2. Los van het feit dat mijn script dan te laat zou worden uitgevoerd (dat zie ik aan de volgorde in /etc/rc2.d/) gebeurt er ook helemaal niks.

Ik maak ongetwijfeld ergens een denkfout, of mijn script klopt niet, maar ik loop vast op dit punt. Iemand nog tips/ideeën?

[mace]

_JGC_ schreef op woensdag 19 december 2012 @ 12:10:

Heb bij die server vooral in het begin last gehad van uitvallende SSDs door firmware bugs. Uiteindelijk de interface geforceerd naar 3Gbit/s, maar sinds 000F kan die gewoon weer naar 6Gbit/s. Latere firmwares heb ik nog niet geflasht, zie de noodzaak niet echt.

000F is nog steeds de beste firmware want in 010G is weer een andere bug geïntroduceerd die er bij 040H nog niet uitgehaald is.

[Mentalist]

Wat voor bug?

[Trax_Digitizer]

Het script om de inhoud van /var/log/ op tmpfs te behouden bij een reboot heb ik inmiddels werkend. Ik heb insserv gebruikt om het script aan bepaalde runlevels toe te voegen. Dat werkte meteen. Dit in tegenstelling tot sysv-rc-conf.

Daarnaast ik twee aparte scripts gemaakt, vanwege verschillende boot/shutdown dependencies die ik niet verenigd kreeg in een enkel script. Kijk hier voor mijn recente blogpost met daarin de definitieve scripts.

Daarnaast loop ik nog steeds met de onderstaande vragen rond.

Trax_Digitizer schreef op zaterdag 22 december 2012 @ 16:33:
...
Ik vraag me overigens af of mijn SSD nu goed 'gealigned' is. Zie hieronder de output van 'fdisk -lu'

code:

Disk /dev/sda: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0007eb5f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   250068991   125033472   83  Linux

Hier las ik dat je dan de startsector * 512 / 4096 moet doen. En als daar dan een rond getal uitkomt, dan zou de SSD goed gealigned zijn. In mijn geval is dat een geheel getal, maar ik begrijp niet goed waarom dit dan klopt. Is dit niet afhankelijk van de "clustergrootte"? En moet dit voor mijn SSD niet 4096 bytes zijn ipv de 'oude' 512 bytes?

Met name de 512B of 4K "clustergrootte". Anyone?

[mace]

W3ird_N3rd schreef op maandag 31 december 2012 @ 00:34:
Wat voor bug?

In die firmwares zit een bug waardoor de drive in sommige gevallen niet door de bios wordt herkend.

http://forum.crucial.com/...OS-after-BSOD/td-p/110660

[Verwijderd]

Ik heb net een nieuwe PC in elkaar gezet en Ubuntu 12.04.2 erop geinstalleerd. Op zich ging dat allemaal vlekkeloos, totdat ik de veel vertelde tip om de "noatime" parameter toe te voegen aan de root partitie in fstab ging uitvoeren. Zodra ik dit gedaan had, boot mijn systeem niet meer grafisch op en kan ik alleen inloggen op de consoles tty[0-6]. (Her)Kent iemand dit probleem?

Als ik dan in de console de noatime parameter weer weghaal en reboot is er weer niets aan de hand. Ik heb al aardig wat gegoogled, maar kan echt niets vinden.

De fstab regel die wel boot:

UUID=9d02a572-f593-4e0d-9980-7ded33ed2f1b / ext4 errors=remount-ro 0 1

en dit maakt mijn systeem stuk:

UUID=9d02a572-f593-4e0d-9980-7ded33ed2f1b / ext4 errors=remount-ro,noatime 0 1

Bedankt!

[Room42]

Verwijderd schreef op dinsdag 05 maart 2013 @ 00:09:
[...]

Ik geloof dat je de noatime voor de errors=remount-ro moet zetten.

[ Voor 63% gewijzigd door Room42 op 05-03-2013 00:32 ]

[Verwijderd]

Bedankt voor je reactie, maar ik was het vergeten er bij te zetten: dat heb ik ook wel geprobeerd. Is niet echt een verschil, alleen blijft hij dan ook af-en-toe hangen op een zwart scherm met een blinkende underscore.

[Ozzie]

Ik zou het proberen met defaults,noatime,errors=remount-ro als opties, maar weet niet of het gaat werken en kan het momenteel ook niet uitproberen.

[Hero of Time]

Vreemd dat Ubuntu niet standaard de juiste opties toepast in fstab voor op SSDs. Mijn Debian Sid heeft dat wel gedaan. Alleen op m'n macbook niet omdat 't in BIOS mode draait waardoor TRIM e.d. niet werkt. Even hoger of pagina terug heb ik mijn opties al eens gepost en andere hebben dat ook gedaan. Door alleen noatime te gebruiken zal je niet veel extra krijgen uit je SSD, discard bijvoorbeeld zou TRIM moeten inschakelen.

[Ertepeller]

noatime expliciet opgeven heeft geen zin meer...

Tegenwoordig is relatime de default: access time wordt alleen bijgewerkt als de vorige access time ouder is dan de laatste modification time. Sommige applicaties kunnen er niet tegen als atime ouder is dan mtime (bv. mutt).

Dus als je een bestand wijzigt, wordt alleen de 1e keer dat hij daarna wordt gelezen de access time geupdate. Alle reads daarna niet.

In de praktijk zul je geen verschil in performance kunnen merken tussen mounten met en zonder noatime.

[Verwijderd]

Nou ja, wellicht gooi ik het er dan maar uit ja. Ik zag hier en daar al staan dat voor ext4 noatime het ook niet echt nodig meer is. Maar toch raden vele mensen het nog steeds aan.
@Ozzie: ik heb nog allerlei verschillende volgordes geprobeerd, maar no joy. Het rare is wel dat ik dus gewoon in de tty1 console kan inloggen en dan is vervolgens de SSD wel gewoon gemount met noatime optie volgens "> mount". Ik krijg alleen met geen mogelijkheid een grafische omgeving gestart.

[Hero of Time]

Dan moet je kijken naar je Xorg.0.log. Die geeft aan wat er dan mis is. Ik heb met een oudere kernel gehad dat de nVidia driver niet meer werkte omdat ik IOMMU aan had, was een bug in de kernel die ondertussen is opgelost.
Het is dus mogelijk dat noatime iets doet wat je video driver niet fijn vind. Ik zie nu dat ik bij elke ext4 mount noatime heb staan. Voor / staat er dit:

code:

noatime,discard,errors=remount-ro

Andere partities op m'n SSD hebben 'defaults' ipv 'errors=remount-ro'. Standaard zo gedaan door de Debian installer.

[Verwijderd]

Ok, thanks voor de tip. Ik zal er morgen even op gaan letten. De keren dat het fout ging kon ik in dmesg in ieder geval nooit iets vinden. Het rare (maar ook wel enge) is dat hij vanochtend tijdens het testen is gaan booten met noatime... En nu al een aantal keer herstart en nog steeds doet hij het...

[Hero of Time]

Niet toevallig updates gehad gisteren?

[Verwijderd]

Nee, geen updates gehad, niet dat ik weet. En vanochtend deed hij het weer een keertje. Nu meteen de Xorg.0.log gekopieerd en na een reboot (zonder iets te veranderen) ging het weer goed.

Een relevantie sectie uit de log:

[     1.596] (EE) intel(0): [drm] failed to set drm interface version.
[     1.597] (EE) intel(0): Failed to become DRM master.
[     1.597] (II) intel(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[     1.597] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[     1.597] (==) intel(0): RGB weight 888
[     1.597] (==) intel(0): Default visual is TrueColor
[     1.597] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge Desktop (GT2)
[     1.597] (--) intel(0): Chipset: "Ivybridge Desktop (GT2)"
[     1.597] (II) UnloadModule: "intel"
[     1.597] (II) Unloading intel
[     1.597] (EE) Screen(s) found, but none have a usable configuration.
[     1.597] 
Fatal server error:
[     1.597] no screens found

En hier lijkt het voor het eerst fout te gaan vergeleken met een "goede" Xorg.0.log:

[     1.316] drmOpenDevice: node name is /dev/dri/card0
[     1.471] drmOpenDevice: open result is 9, (OK)
[     1.471] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
[     1.471] drmOpenDevice: node name is /dev/dri/card0
[     1.471] drmOpenDevice: open result is 9, (OK)
[     1.471] drmOpenByBusid: drmOpenMinor returns 9
[     1.471] drmOpenByBusid: Interface 1.4 failed, trying 1.1  <-- deze regel is nieuw in de foute log
[     1.471] drmOpenByBusid: drmGetBusid reports <--- de goede log report hier weer "pci:0000:00:02.0" en gaat dan gewoon door met het scherm herkennen etc

Maar goed, nu weet ik niet meer zeker of noatime de boosdoener is. Het leek tijdens het testen wel echt super consistent: met noatime geen boot, zonder noatime wel booten. Iemand een tip hoe ik vanuit deze logs kan verder zoeken/testen?

Het lijkt op https://bugs.launchpad.ne...g-video-intel/+bug/927684 of https://bugs.launchpad.ne...g-video-intel/+bug/899725, dus ik heb plymouth gedisabled, maar ja, het probleem deed zich niet altijd meer voor dus of het echt werkt weet ik pas over een week ofzo, haha.

[Hero of Time]

Doe even nieuw topic openen hiervoor. Dit gaat niet meer over SSDs tenslotte .