SSD's en Linux: tips en trucs

[KarlMarX]

Bedankt! Het lijkt gelukt. Na een rm en een sync staan de sectoren gelijk weer op 0000

Klopt mijn fstab nog wel zo?

# /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 defaults 0 0
# / was on /dev/sda1 during installation
UUID=b2b34de0-e46a-47d5-967d-cfbf5c266854 / ext4 noatime,discard,errors=remount-ro 0 1
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

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


Op de tmpfs line en de noatime en discard na stond alles zo al na een schone ubuntu server installatie.

Ik snap niet waarom er "UUID=b2b34de0-e46a-47d5-967d-cfbf5c266854 /" staat in plaats van gewoon /dev/sda1 ?

[Dirk]

Je hebt geen swappartitie en geen aparte /home? /tmp op tmpfs zou ik niet eens gedaan hebben, al zal het ook geen schade doen.

En de keuze voor de UUID in plaats van de /dev/sda1 is simpel: de UUID blijft altijd gelijk zolang je de schijf maar niet herpartitioneert, de udev lokatie kan redelijk eenvoudig veranderen.

[KarlMarX]

Swap werd sterk ontraden als je een SSD gebruikt. (Ik heb geen andere schijven in deze server). /home wilde ik wel apart, maar had het even over het hoofd gezien en nu was ik al zo blij dat het alignen en trimmen eindelijk gelukt was...

/tmp in ram werd wel overal aangeraden voor SSD's volgens mij...

Kan ik nu alsnog een aparte partitie voor /home maken?

[Dirk]

Alleen met niet-intelligente controllers is swap op de ssd sterk af te raden, met een goede controller als die van Intel is het geen probleem. Je maakt er als het goed is toch niet al te veel gebruik van. Voor /tmp in ram geldt dezelfde redenatie.
Als je installatie nog niet echt customised zou ik de aparte partitie voor /home maken door gewoon te herpartitioneren en herinstalleren, resizen kost relatief veel tijd. Bij het partitioneren heb je als voordeel dat als de eerste partitie aligned is, de rest dat ook is.

[ Voor 3% gewijzigd door Dirk op 17-03-2010 14:11 ]

[KarlMarX]

Nou ik heb de server al van monitor en toetsenbord afgekoppeld en in de meterkast geïnstalleerd. Het zou dan toch praktischer zijn om het via de shell op afstand te regelen... Tijd is minder van belang.

Ik heb alleen nog niet zoveel ervaring met het partitioneren en vooral herpartitioneren van bestaande linux installaties op afstand...

[Shadow_Dragon]

Ehm, deze thread een beetje uit het oog verloren...

Nog wat extra info:
Native Trim support zit pas in kernel 2.6.33 series. Dit komt omdat er nog patch van libata nodig was en die patch is pas toegevoegd een paar uur na de release van 2.6.32. Hierdoor is de kans groot dat je in Ubuntu Lucid standaard geen native Trim gaat hebben tenzij ze het ooit gaan backpoorten... Je hebt dus twee mogelijkheden ofwel, zoals reeds gesuggereert, de PPA-mainline kernels installeren ofwel wachten tot Lucid+1.

Daarnaast is Ext4 niet het enigste filesystem dat met Trim overweg kan, Btrfs bijvoorbeeld kan dit ook en er zijn er waarschijnlijk nog een paar... (Kan niet direct een bron vinden...)

Daarnaast lees ik op overscheidene fora dat sommige beweren dat het niet gegarandeerd is dat Trim commando onmidelijk uitgevoerd moet worden. We zijn nog aan het uitpuzzelen of dit effectief waar is, persoonlijk twijfel ik aan dat statement (Ik denk dat Trim bij die mensen gewoonweg niet werkt ), en zo ja in welke situaties dit geldt. Vandaar dat ik wat info aan het verzamelen ben, bij wie het wel onmiddelijk werkt en bij wie niet.

@Boondock-Saint: Ik lees dat bij jou, het testje van Octoploid, het Trimmen onmiddelijk effect had. Wat voor SSD heb je, kon het niet vinden in je profiel-inventaris En welke aanpassingen heb je aangebracht (zoals de mount-optie discard, ...)
* Linux kernel 2.6.33-rc8

@KarlMarX: Ik lees dat bij jou, het testje van Octoploid, het Trimmen onmiddelijk effect had. Wat voor SSD heb je, kon het niet vinden in je profiel-inventaris En welke kernel draai je?

Anderen mogen natuurlijk ook spontaan hun configuratie posten.

Overzicht:
Bedankt allemaal voor de medewerking!
*** KarelMarX ***
** Immediate Trim: Yes
* Linux kernel: 2.6.33
* Filesystem: ext4
* Mountoptions: noatime,discard,errors=remount-ro
* SSD: Intel X25-V 40GB, FW: 2CV102HD

*** jeroen__online ***
** Immediate Trim: Yes
* Linux kernel: 2.6.33-rc7, 2.6.33
* Filesystem: ext4
* Mountoptions: discard
* SSD: Intel X-25V 40GB, FW: 2CV102HD

*** Rprp ***
** Immediate Trim: Yes
* Linux kernel: 2.6.33-1
* Filesystem: ext4
* Mountoptions: discard
* SSD: Intel X-25M 160GB, FW: 2CV102HD

*** Snow_King ***
** Immediate Trim: Yes
* Linux kernel: 2.6.33-020633-generic (Ubuntu's mainline ppa)
* Filesystem: ext4
* Mountoptions: discard
* SSD: Intel X-25M 80GB, FW: 2CV102G9

[ Voor 15% gewijzigd door Shadow_Dragon op 29-03-2010 13:38 . Reden: Lijstje aangevuld ]

[KarlMarX]

Ik gebruik een Intel X25-V 40GB en Ubuntu server 9.10 en die heb ik geupgrade naar kernel 2.6.33. Dat was kinderlijk eenvoudig... Zitten daar eigenlijk nog nadelen aan?

[Shadow_Dragon]

En welke firmware draai je op die Intel?

Nadelen, tja, niet echt. Het enigste is natuurlijk dat alles afgesteld wordt op de 2.6.32 kernel, dus je kan wat optimalisaties mislopen, maar voor de rest geen idee eigenlijk...

[KarlMarX]

Ik heb de meest recente van de Intel website. Weet even niet uit mijn hoofd welke dat is. En ik gebruik de machine als server en weet eigenlijk niet hoe je onder linux de firmware versie kan zien?

[_JGC_]

hdparm -i /dev/sda, waarbij /dev/sda je SSD dan is. Staat als het goed is de firmware versie op de eerste regel met FwRev.
Wat betreft die 2.6.33 kernel op ubuntu: het werkt gewoon, en zal niet minder optimaal draaien dan de originele 2.6.32 kernel. Je moet er alleen wel rekening mee houden dat Ubuntu zo nu en dan security updates en bugfixes uitbrengt voor 2.6.32, die moet je met 2.6.33 zelf onderhouden.

[Shadow_Dragon]

KarlMarX schreef op woensdag 24 maart 2010 @ 09:54:
Ik heb de meest recente van de Intel website. Weet even niet uit mijn hoofd welke dat is.

Dat zal dan waarschijnlijk de 02HD zijn. Oké, mercikes voor de info.

[KarlMarX]

Ja dat is hem.

Dit is de output van hdparm -i:
FwRev=2CV102HD

[Rprp]

Mooi, dat TRIM support zeg.

Ik bezit een server met een 160GB Intel SSD waar +- 80GB per dag op wordt geschreven, TRIM komt dus wel van pas hier.

Echter, ik zit nog op Debian Lenny en die draait op 2.6.26 zo uit m'n hoofd, de bedoeling is dus dat ik het volgende uitvoer:
* Ext3 naar ext4 converteren
* 2.6.33 compileren
* Trim testen

Zie ik nog dingen over het hoofd, of is dit voldoende? Wachten op een nieuwe Debian release duurt helaas ook weer zo lang..

[jeroen__online]

Rprp schreef op woensdag 24 maart 2010 @ 14:14:
Mooi, dat TRIM support zeg.

Ik bezit een server met een 160GB Intel SSD waar +- 80GB per dag op wordt geschreven, TRIM komt dus wel van pas hier.

Echter, ik zit nog op Debian Lenny en die draait op 2.6.26 zo uit m'n hoofd, de bedoeling is dus dat ik het volgende uitvoer:
* Ext3 naar ext4 converteren
* 2.6.33 compileren
* Trim testen

Zie ik nog dingen over het hoofd, of is dit voldoende? Wachten op een nieuwe Debian release duurt helaas ook weer zo lang..

Je had 'm natuurlijk allang gevonden, maar ter overvloede vermeld ik het toch: m'n post over hoe ik m'n Debian Lenny installatie heb voorzien van TRIM support. Daar zie je direct dat je ook GRUB2 v1.97 of hoger moet installeren en hoe je aan de andere voorwaarden kunt voldoen. De volgorde is ook niet onbelangrijk trouwens

[Rprp]

jeroen__online schreef op woensdag 24 maart 2010 @ 19:36:
[...]

Je had 'm natuurlijk allang gevonden, maar ter overvloede vermeld ik het toch: m'n post over hoe ik m'n Debian Lenny installatie heb voorzien van TRIM support. Daar zie je direct dat je ook GRUB2 v1.97 of hoger moet installeren en hoe je aan de andere voorwaarden kunt voldoen. De volgorde is ook niet onbelangrijk trouwens

Ah, bedankt! denk dat ik erover heen heb gelezen.

Alles werkt naar behoren, totdat ik de optie 'discard' meegeef.. Als die optie aanstaat wil de server niet booten, filesystem blijft read-only. Alles is wel ext4 volgens 'mount' e.d.

Iemand enig idee hoe dit kan komen?

EDIT:
/dev/sda1 on / type ext4 (rw,noatime,errors=remount-ro)
FwRev=2CV102HD

[ Voor 4% gewijzigd door Rprp op 25-03-2010 14:36 ]

[_JGC_]

Bij het opstarten van je systeem zal je filesystem readonly gemount worden. Tijdens het opstarten wordt die rw gemount met de opties die je in fstab hebt staan. Als daar een niet-ondersteunde optie tussen staat werkt dat niet en blijft je filesystem readonly.
Lijkt erop dat je kernel geen ext4 trim support heeft dus.

[Rprp]

_JGC_ schreef op donderdag 25 maart 2010 @ 14:51:
Bij het opstarten van je systeem zal je filesystem readonly gemount worden. Tijdens het opstarten wordt die rw gemount met de opties die je in fstab hebt staan. Als daar een niet-ondersteunde optie tussen staat werkt dat niet en blijft je filesystem readonly.
Lijkt erop dat je kernel geen ext4 trim support heeft dus.

server:~/hdparm-9.28/wiper# uname -a
Linux * 2.6.33.1 #1 SMP

Laatste kernel die er op het moment is en volgens mij support moet hebben.

Echter, wiper.sh geeft ook een fout:
/dev/sda1: cannot TRIM ext3 filesystem when mounted read-write, aborting.

hmm...

[_JGC_]

wiper.sh geeft die fout omdat je je filesystem R/W gemount hebt, je moet dat ding eerst R/O mounten voor je die wipetool kunt uitvoeren. Verder geeft dat ding aan dat je ext3 hebt, maar dat kan ook cosmetisch zijn. Wat gebeurt er als je "mount -o remount,discard /" geeft als commando? Als je filesystem geen ext4 is, dan zal dat een foutmelding geven.
Overigens kan de ext4 driver tegenwoordig ook ext3 en ext2 filesystems aan. Dankzij een paar prachtige bugs zou ik dat nog niet gebruiken. Dataverlies heb ik er nog niet mee gezien, maar de berekening van vrije ruimte klopt van geen kant.

[Rprp]

server:/# mount -o remount,discard /
mount: / not mounted already, or bad option

Dat werkt dus ook niet echt.. Geprobeerd met -t ext4 e,d, blijft maar meldingen geven.

Ik heb trouwens de .config files hier weggehaald: http://merkel.debian.org/~jurij/

[ Voor 20% gewijzigd door Rprp op 25-03-2010 22:00 ]

[Erhnam]

Zijn er hier mensen die trouwens ssd met een non-ssd combineren? Ik wil een stil systeem wat je overdag niet kan horen, waarvan de SSD de hoofd disk is.

Een tweede, grotere, schijf wil ik dan gebruiken voor het betere werk. Deze moet gaan spinnen zodra hiervan gelezen gaat worden. Is zoiets mogelijk?

[Room42]

Dat heet toch gewoon powermanagement? En om te voorkomen dat er per ongeluk data nodig is van de schijf (en hij dus ongewenst gaat draaien), kun je hem unmounten als je hem niet nodig hebt.

[ Voor 10% gewijzigd door Room42 op 26-03-2010 10:11 ]

[jeroen__online]

Rprp schreef op donderdag 25 maart 2010 @ 21:51:
server:/# mount -o remount,discard /
mount: / not mounted already, or bad option

Dat werkt dus ook niet echt.. Geprobeerd met -t ext4 e,d, blijft maar meldingen geven.

Ik heb trouwens de .config files hier weggehaald: http://merkel.debian.org/~jurij/

Hmm, weet je zeker dat je filesystem goed is geconvert naar EXT4? Volgens mij kan EXT3 wel als EXT4 gemount worden, maar zodra je EXT4 specifieke dingen gaat toepassen gaat ie raar doen. Voor een toelichting, zie de sectie "Converting an ext3 filesystem to ext4" van deze link.

Erhnam schreef op vrijdag 26 maart 2010 @ 09:57:
Zijn er hier mensen die trouwens ssd met een non-ssd combineren? Ik wil een stil systeem wat je overdag niet kan horen, waarvan de SSD de hoofd disk is.

Een tweede, grotere, schijf wil ik dan gebruiken voor het betere werk. Deze moet gaan spinnen zodra hiervan gelezen gaat worden. Is zoiets mogelijk?

Tuurlijk is dat mogelijk, ik draai zelf zo'n opstelling onder Debian met o.a.:
AMD Athlon X2 4850e
Gigabyte GA-MA74GM-S2H (AMD 740G chipset)
2x 1GB PC6400 DDR2
Samsung HD200HJ (200GB)
WD WD2500AAJS-6 (250GB)
Intel X25-V 40GB SSD

M'n rootfs staat op de SSD, de Samsung en WD schijven hangen in software RAID-1 en gaan na 30mins uit, works like a charm Verschillende mappen van m'n rootfs zijn via mount's bind-optie gekoppeld aan een map op m'n raid-array, bijvoorbeeld alleen /home/jeroen/downloads/, zodat de schijven niet elke keer opspinnen bij het openen van m'n home directory. Lekker stil, snel en zuinig (33W idle met schijven in standby) en toch een hoop opslagcapaciteit

[_JGC_]

Heb hier ook die setup met een OCZ Vertex 30GB, maar dan met /home op een Spinpoint F3. Op zich is die disk wel snel, maar de performancewinst van je SSD merk je niet omdat je mailbox en browsercache nog op trage schijfopslag staan. Beter is het dan om zoals hierboven te doen en alleen de grote directories op je normale hdd te plaatsen.

Overigens had ik hiervoor 2x250GB deels in RAID0, heb nu gewoon 1x500GB gekocht: ding is sneller dan die 2 oude schijven en vreet een stuk minder stroom.

[Snow_King]

Ik zit zo te lezen over TRIM support in Linux, maar wat ik nog nergens kan vinden, hoe werkt dit met LVM?

Wat als ik ext4 gebruik bovenop LVM en daar onder een SSD met TRIM support heb? Werkt dat dan wel?

Waarom ik dit vraag: Ik kijk er naar uit server optiek, Areca komt met de 1880 serie waar TRIM support voor SSD's in zit, daar zou ik graag een aantal TRIM supported SSD's achter hangen, maar op het Areca VolumeSet gebruik ik graag LVM.

Iemand enig idee? Zoeken wees weinig uit.

[_JGC_]

http://comments.gmane.org/gmane.comp.file-systems.ext4/17945

Beetje googlen...

Komt erop neer dat het nog niet kan, en dat de ontwikkelaar die ermee bezig is zegt dat ie het voor 2.6.35 klaar te hebben. Even later komt ie erachter dat het veel meer werk is, dus het kan nog wel een hele tijd duren voor LVM/DM met trim gaat werken.

[Snow_King]

Mja, ik maar zoeken op LVM en TRIM... Even lezen, ziet er interessant uit.

[Rprp]

jeroen__online schreef op vrijdag 26 maart 2010 @ 10:38:

Hmm, weet je zeker dat je filesystem goed is geconvert naar EXT4? Volgens mij kan EXT3 wel als EXT4 gemount worden, maar zodra je EXT4 specifieke dingen gaat toepassen gaat ie raar doen. Voor een toelichting, zie de sectie "Converting an ext3 filesystem to ext4" van deze link.

Ja, dat weet ik zeker. Het converten was echter wel binnen (2 sec?) klaar. De fsck erover duurde overigens 2-3 minuten. Geen idee of dit zo hoort?

Uitgevoerd via Ubuntu live CD:
tune2fs -O extents,uninit_bg,dir_index /dev/sda1
e2fsck -fDC0 /dev/sda1

[jeroen__online]

Rprp schreef op vrijdag 26 maart 2010 @ 14:26:
[...]


Ja, dat weet ik zeker. Het converten was echter wel binnen (2 sec?) klaar. De fsck erover duurde overigens 2-3 minuten. Geen idee of dit zo hoort?

Uitgevoerd via Ubuntu live CD:
tune2fs -O extents,uninit_bg,dir_index /dev/sda1
e2fsck -fDC0 /dev/sda1

Converten was bij mij ook in een oogwenk gedaan, dat lijkt allemaal goed te zijn gegaan. Wat zegt je dmesg over het mounten/fstype? Heb je in GRUB2 ook de optie rootfstype=ext4 meegegeven?

[Snow_King]

Let wel op, bij een convert is je filesystem eigenlijk nog ext3, de nieuw aangemaakt files worden pas volgens het ext4 formaat aangemaakt.

[Rprp]

jeroen__online schreef op vrijdag 26 maart 2010 @ 15:04:
[...]

Converten was bij mij ook in een oogwenk gedaan, dat lijkt allemaal goed te zijn gegaan. Wat zegt je dmesg over het mounten/fstype? Heb je in GRUB2 ook de optie rootfstype=ext4 meegegeven?

Aha, ik gaf die optie telkens aan in het opstart scherm van GRUB2 zelf (dmv C -> console -> add).

Toegevoegd aan de config file, update-grub2 en nu mount ie wel met discard. Tevens werkt TRIM nu instant

** Immediate Trim: Yes
* Linux kernel: 2.6.33-1
* Filesystem: ext4
* Mountoptions: discard
* SSD: Intel X-25M 160GB, FW: 2CV102HD

[Snow_King]

** Immediate Trim: Yes
* Linux kernel: 2.6.33-020633-generic
* Filesystem: ext4
* Mountoptions: discard
* SSD: Intel X-25M 80GB, FW: 2CV102G9

Dit is mijn Ubuntu 9.10 desktop met een kernel van Ubuntu's kernel ppa: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33/

[ Voor 30% gewijzigd door Snow_King op 29-03-2010 13:28 ]

[Verwijderd]

Mooi, dat TRIM support zeg.

Ik bezit een server met een 160GB Intel SSD waar +- 80GB per dag op wordt geschreven, TRIM komt dus wel van pas hier.

Echter, ik zit nog op Debian Lenny en die draait op 2.6.26 zo uit m'n hoofd, de bedoeling is dus dat ik het volgende uitvoer:
* Ext3 naar ext4 converteren
* 2.6.33 compileren
* Trim testen

Zie ik nog dingen over het hoofd, of is dit voldoende? Wachten op een nieuwe Debian release duurt helaas ook weer zo lang..

Je hoeft niet naar kernel 2.6.33 als je dat niet wil. Je kan ook de laatste versie van hdparm nemen die heeft ook trim support. Je zal dan alleen een scripje moeten gebruiken bij het opstarten. of een cron job

[ Voor 51% gewijzigd door Verwijderd op 01-04-2010 10:19 ]

[RielN]

Ik haal bij Ubuntu 9.10 op een verse installatie met 1.40 firmware maar 95MB/s

Kan het zijn dat de alignment van mij niet klopt?

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
Schijf-ID: 0x8a792c27

 Apparaat Opstart   Begin       Einde     Blokken   ID  Systeem
/dev/sda1   *          63    23936849    11968393+  83  Linux
/dev/sda2        59858190    62524979     1333395    5  Uitgebreid
/dev/sda3        23936850    59858189    17960670   83  Linux
/dev/sda5        59858253    62524979     1333363+  82  Linux wisselgeheugen

Partitietabel-items liggen niet in schijfvolgorde.



riel@laptopriel:~$ sudo fdisk -l /dev/sda

Schijf /dev/sda: 32.0 GB, 32017047552 bytes
255 koppen, 63 sectoren/spoor, 3892 cilinders
Eenheid = cilinders van 16065 * 512 = 8225280 bytes
Schijf-ID: 0x8a792c27

 Apparaat Opstart   Begin       Einde     Blokken   ID  Systeem
/dev/sda1   *           1        1490    11968393+  83  Linux
/dev/sda2            3727        3892     1333395    5  Uitgebreid
/dev/sda3            1491        3726    17960670   83  Linux
/dev/sda5            3727        3892     1333363+  82  Linux wisselgeheugen

[ Voor 18% gewijzigd door RielN op 01-04-2010 11:15 ]

[Shadow_Dragon]

Verwijderd schreef op donderdag 01 april 2010 @ 10:17:
[...]
Je hoeft niet naar kernel 2.6.33 als je dat niet wil. Je kan ook de laatste versie van hdparm nemen die heeft ook trim support. Je zal dan alleen een scripje moeten gebruiken bij het opstarten. of een cron job

Ja, maar native trim heeft toch wel zijn meerwaarde over de wiper-functionaliteit van hdparm. De wiper inflate een bestand zodat je volledige schijf gevuld is en gaat dan die LBA's trimmen en smijt het desbetreffende bestand weg. Native trim gebeurt gewoon on the fly, zonder te moeten inflaten.

Enigste voordeel is dat als de frequentie van trim-bundels niet goed afgesteld is op uw persoonlijk gebruikt van de SSD kan je performance verlies tegenkomen. Dan is het zelf schedulen van trims aangewezen.

RielN schreef op donderdag 01 april 2010 @ 11:15:
Ik haal bij Ubuntu 9.10 op een verse installatie met 1.40 firmware maar 95MB/s

De recenste en ondesteunde firmware versie is 1.5 Er zitten een hoopje bugfixen in dus zeker het overwegen of je die FW gaat flashen waart.

RielN schreef op donderdag 01 april 2010 @ 11:15:
Kan het zijn dat de alignment van mij niet klopt?

Op basis daarvan gok ik dat dat een OCZ Vertex 30GB is. Die heeft een read-block van 4KiB en een write-block van 512KiB.
/dev/sda1 is niet gealigned (63 * 512 bytes, is niet deelbaar door 4KiB of door 512KiB).
/dev/sda3 is niet gealigned (idem)
/dev/sda5 is niet gealigned (idem)

[ Voor 31% gewijzigd door Shadow_Dragon op 01-04-2010 17:49 ]

[Loekie]

Ik vind het maar lastig met alignen, ik heb een Intel X25-M 80 GB.
Ik heb dus een knoppix-cd gestart en daar in de terminal:

code:

fdisk -S 32 -H 32 /dev/sda

Ingegeven, hierna op cylinder 2 een partitie gestart en aan het eind een swap overgehouden(ik houd niet van kleine bootpartities).
Nu wordt er gezegd dat je met fdisk -l/u kunt checken of het ge-alligned is, waar moet je dan op letten?

Ik wil het ding gaan gebruiken als schijf in m'n homeserver en als het op deze manier wat beter presteerd is mooi meegenomen..

Daarnaast is het ook niet echt fijn dat op verschillende blogs totaal andere parameters aan fdisk worden meegeven als sector en head-size...

[Shadow_Dragon]

@Loekie: Als je met het commando

code:

fdisk -lu /dev/sda

krijgt je de start-locaties van je partities in sectors (512 bytes). Je moet dan checken of je begin deelbaar is door de hoeveelheid waarop je wil alignen.

Met de opties -H 32 -S 32, maak je cylinders van 32 * 32 = 1024 sectors of 512 KiB. De erase-block-size van de Indilinx controller is 512 KiB, dus je bent aligned.

[ Voor 0% gewijzigd door Shadow_Dragon op 06-08-2011 12:13 . Reden: typo fix ]

[H!GHGuY]

Shadow_Dragon schreef op dinsdag 23 maart 2010 @ 16:47:
Daarnaast lees ik op overscheidene fora dat sommige beweren dat het niet gegarandeerd is dat Trim commando onmidelijk uitgevoerd moet worden. We zijn nog aan het uitpuzzelen of dit effectief waar is, persoonlijk twijfel ik aan dat statement (Ik denk dat Trim bij die mensen gewoonweg niet werkt ), en zo ja in welke situaties dit geldt. Vandaar dat ik wat info aan het verzamelen ben, bij wie het wel onmiddelijk werkt en bij wie niet.

Ik vermoed een beetje het klok-klepel syndroom.

Het ATA TRIM-commando heeft een groot probleem: het kan niet gequeued worden.

Dit betekent dat het OS moet wachten tot alle voorgaande transacties klaar zijn om dan 1 TRIM command op te sturen, wachten tot dit klaar is en dan verder gaan met normale acties.
Aangezien TRIM lang kan duren, kun je je gaan afvragen wanneer je best TRIM doet.

Wanneer je compileert bvb, worden veel files geremoved en andere aangemaakt. Mocht elke remove een TRIM naar de drive sturen dan kon je beter "upgraden" naar een 4.2k RPM drive.

Er was dus een discussie op LKML, waar men zich afvroeg wanneer men best TRIM uitvoerde op de drive.
Daar kwamen ook de observaties aan bod over hoe Win7 dit doet. Deze zou volgens enkele heuristieken werken (bvb minimaal X% van de drive gebruikt, etc).

Dit wil dus zeggen dat als je een file verwijdert, dit mogelijk niet automatisch betekent dat er een TRIM wordt opgestuurd.

[Boondock_Saint]

Shadow_Dragon schreef op dinsdag 23 maart 2010 @ 16:47:

@Boondock-Saint: Ik lees dat bij jou, het testje van Octoploid, het Trimmen onmiddelijk effect had. Wat voor SSD heb je, kon het niet vinden in je profiel-inventaris En welke aanpassingen heb je aangebracht (zoals de mount-optie discard, ...)
* Linux kernel 2.6.33-rc8

Ik ben het ook een beetje uit het oog verloren

Mijn ssd is een Intel Postville SSDSA2MH080G2C1 80GB

En hier m'n fstab:

# / was on /dev/sdc3 during installation
UUID=71b684b3-783f-420a-b3de-f4aed24f83b7 / ext4 discard,noatime,errors=remount-ro 0 1
# /boot was on /dev/sdc1 during installation
UUID=3035a5c8-c3b4-4adb-b1db-3c465b2967db /boot ext4 discard,noatime 0 2
# /home was on /dev/sdc4 during installation
UUID=edb5c89d-ba30-479d-b3e6-ca9ef02b9e89 /home ext4 discard,noatime 0 2
/dev/mapper/isw_bffchhdjif_store1 /home/jvlek/store ext4 user,auto,rw 0 2
# swap was on /dev/sdc2 during installation
UUID=e07b65fc-a56e-4cd8-93e8-d2915b124fb0 none swap sw 0 0

Die partities zijn later gewijzigd door de installatie van een RAID 1 array.

Kernel swappiness staat overigens op 0, voordat mensen weer met dat swap verhaal aan komen zetten

Tijdens het booten van kubuntu (splash screen uitgezet), klaagt ie wel over illegale opties, maar zoals eerder gezegd: de test werkte gewoon.

Kernel versie weet je al.

[Shadow_Dragon]

@Boondock-Saint: Bedankt voor de reactie!

H!GHGuY schreef op zaterdag 17 april 2010 @ 18:19:
[...]
Ik vermoed een beetje het klok-klepel syndroom.

Het ATA TRIM-commando heeft een groot probleem: het kan niet gequeued worden.

Dit betekent dat het OS moet wachten tot alle voorgaande transacties klaar zijn om dan 1 TRIM command op te sturen, wachten tot dit klaar is en dan verder gaan met normale acties.
Aangezien TRIM lang kan duren, kun je je gaan afvragen wanneer je best TRIM doet.

Wanneer je compileert bvb, worden veel files geremoved en andere aangemaakt. Mocht elke remove een TRIM naar de drive sturen dan kon je beter "upgraden" naar een 4.2k RPM drive.

Er was dus een discussie op LKML, waar men zich afvroeg wanneer men best TRIM uitvoerde op de drive.
Daar kwamen ook de observaties aan bod over hoe Win7 dit doet. Deze zou volgens enkele heuristieken werken (bvb minimaal X% van de drive gebruikt, etc).

Dit wil dus zeggen dat als je een file verwijdert, dit mogelijk niet automatisch betekent dat er een TRIM wordt opgestuurd.

Heb je misschien een linkje liggen naar de desbetreffende discussie? Heb wat moeite om LKML te doorzoeken en het lijkt mij interessant leesvoer
Want dan vraag ik mij meteen af, of alle heuristieken en dergelijke er ook nog wel voor zorgen dat er geen TRIM commando's verloren gaan. Dat de commando's gebundeld moeten worden daar kan ik inkomen, want anders is dat ding echt niet vooruit te branden...

Het is gewoon dat ik mijn vermoedde, dat de Intel-controller bij het ontvangen van een TRIM commando onmiddellijk handelt en de Indilinx-controller niet, wil ontkrachten. En daarvoor is wat meer inzicht in wanneer het OS de commando's stuur wel aangewezen.

[Erhnam]

Is deze al voorbij gekomen?

http://forums.fedoraforum.org/showthread.php?t=215109

[litemotiv]

jeroen__online schreef op woensdag 24 maart 2010 @ 19:36:
[...]

Je had 'm natuurlijk allang gevonden, maar ter overvloede vermeld ik het toch: m'n post over hoe ik m'n Debian Lenny installatie heb voorzien van TRIM support. Daar zie je direct dat je ook GRUB2 v1.97 of hoger moet installeren en hoe je aan de andere voorwaarden kunt voldoen. De volgorde is ook niet onbelangrijk trouwens

wat is het idee achter grub2 in deze context, in welke zin is dat nodig voor trim-support?

[jeroen__online]

litemotiv schreef op zaterdag 01 mei 2010 @ 14:58:
[...]


wat is het idee achter grub2 in deze context, in welke zin is dat nodig voor trim-support?

Zie daarvoor m'n originele bericht:

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

Je GRUB bootloader moet dus wel expliciet EXT4 support hebben, en trim werkt alleen met EXT4 (en HFS+, iig geen EXT3), daarvoor moest ik hier dus GRUB2 installeren/compilen. Het alternatief was een versie van GRUB(1) installeren met EXT4 support, die is er ook meen ik (patched).

[litemotiv]

jeroen__online schreef op zaterdag 01 mei 2010 @ 15:48:
Je GRUB bootloader moet dus wel expliciet EXT4 support hebben, en trim werkt alleen met EXT4 (en HFS+, iig geen EXT3), daarvoor moest ik hier dus GRUB2 installeren/compilen. Het alternatief was een versie van GRUB(1) installeren met EXT4 support, die is er ook meen ik (patched).

ok got it, ik dacht even dat het iets specifieks voor discard was. ext4 werkte hier al prima met grub1, dus dan is upgraden geen issue.

[epic_gram]

kickje...

Ik heb een SSD en ga daar straks ubuntu op installeren, maar ik zou graag mijn documenten, video, muziek, foto's enzovoorts op mijn (grote) HDD zetten. Kan ik dan gewoon mijn mapje /home verplaatsen naar die andere HDD of moet ik meer doen?

[smoking2000]

Het is genoeg om /home naar een andere disk te kopieren (gebruik `rsync -a` voor permissies, symlinks, etc), en die op /home te mounten via /etc/fstab.

Als je nog geen data in /home hebt is het genoeg om tijdens de installatie er voor te kiezen je andere disk op /home te mounten.

[jeroen__online]

epic_gram schreef op maandag 04 oktober 2010 @ 13:43:
kickje...

Ik heb een SSD en ga daar straks ubuntu op installeren, maar ik zou graag mijn documenten, video, muziek, foto's enzovoorts op mijn (grote) HDD zetten. Kan ik dan gewoon mijn mapje /home verplaatsen naar die andere HDD of moet ik meer doen?

Bedoel je permanent of eenmalig? In het eerste geval kun je wellicht bij de installatie al aangeven dat je HDD gemount wordt als /home, dan staat je systeem op de SSD en je home-dir op je HDD (hiervoor moet je waarschijnlijk wel handmatig partitioneren kiezen in de setup).
Anders zou ik je aanraden de bind-functionaliteit van mount te gebruiken, zoek maar eens op 'man mount' en kijk bij de "--bind" optie. Hiermee kun je een bepaalde mappen ook koppelen aan je HDD, zo heb ik dat althans gedaan met m'n SSD en software RAID HDD's onder Debian

[_JGC_]

Let er wel op dat als je /home gebruikt op een normale hdd, dat je de helft van de performanceverbetering niet gaat merken. Je browser slaat zijn cache nml op in een subdirectory van /home, dus die moet je op een of andere manier relocaten naar je SSD of naar tmpfs.
Als ik mijn desktop met /home op een Spinpoint F3 en de rest op een OCZ Vertex vergelijk met mijn laptop met alles op een 160GB Intel SSD, dan is die desktop gewoon tig keer trager. Mag ie wel 3x zoveel geheugen en een quadcore CPU hebben, die laptop is in alle gevallen sneller.

[epic_gram]

Ik bedoel inderdaad permanent.

en @ _JGC_: dankjewel voor je waarschuwing. Kan ik op twee verschillende schijven de /home directory plaatsen, en dan op de SSD de systeembestanden en op die HDD alleen de content zoals video's, muziek, foto' s en alles?

Bijvoorbeeld:

op de SSD /home/epic_gram/.mozilla en de rest

en op die HDD /home/epic_gram/<downloads, video, music, enz>

Of werkt dat niet?

Alvast bedankt voor de reacties!

[deadinspace]

epic_gram schreef op maandag 04 oktober 2010 @ 14:31:
en @ _JGC_: dankjewel voor je waarschuwing. Kan ik op twee verschillende schijven de /home directory plaatsen, en dan op de SSD de systeembestanden en op die HDD alleen de content zoals video's, muziek, foto' s en alles?

Ik zou aanraden /home gewoon op je SSD te laten, en dan alleen voor bulk-opslag iets anders te verzinnen.

Je zou bijvoorbeeld je harddisk kunnen mounten onder /media/storage (oid, verzin wat leuks), en dan symlinks te maken a la /home/epic_gram/Video -> /media/storage/Video. In je homedir staat namelijk veel kleine meuk (denk aan instellingen e.d.) die je graag op je SSD wil, en relatief weinig grote dingen (je noemde zelf al: downloads, video, muziek) die beter op je HDD kunnen.

(in plaats van symlinks kun je ook bind mounts gebruiken voor die directory, ik denk dat dat is waar jeroen__online op doelde)

[epic_gram]

deadinspace schreef op maandag 04 oktober 2010 @ 15:01:
[...]
(in plaats van symlinks kun je ook bind mounts gebruiken voor die directory, ik denk dat dat is waar jeroen__online op doelde)

Dat gaat hem worden, hartelijk bedankt iedereen!

[DJ-Promo]

Ik draai nu Ubuntu 10.10 en heb discard toegevoegd aan me fstab maar hoe zie ik dat overzicht wat jullie posten ? Iets met dsmeg ?

Rprp schreef op maandag 29 maart 2010 @ 11:59:
[...]


Aha, ik gaf die optie telkens aan in het opstart scherm van GRUB2 zelf (dmv C -> console -> add).

Toegevoegd aan de config file, update-grub2 en nu mount ie wel met discard. Tevens werkt TRIM nu instant

** Immediate Trim: Yes
* Linux kernel: 2.6.33-1
* Filesystem: ext4
* Mountoptions: discard
* SSD: Intel X-25M 160GB, FW: 2CV102HD

[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.

[Anoniem: 426707]

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]

Anoniem: 426707 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.

[Anoniem: 426707]

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 Anoniem: 426707 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]

Anoniem: 426707 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?

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!

[Anoniem: 426707]

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]

Anoniem: 426707 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.

[Anoniem: 426707]

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.

[Anoniem: 426707]

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

[nubn]

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 nubn 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.

[nubn]

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 ]

[nubn]

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 nubn 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 ]