Voor mijn Dell E6230 heb ik een Samsung 840 EVO vervangen door een Crucial MX200 en de performance met schrijven is bedroevend langzaam. Ook met een onlangs aangeschafte m550 mSATA 512 GB in mijn Dell E7240 heb ik precies dezelfde ervaringen. Ik houd het voor nu even bij de m550, omdat ik vermoed dat precies dezelfde oorzaak ook geldt voor de MX200.
Hieronder even uiteengezet wat de situatie is, wat ik gemeten heb. Heeft iemand een idee wat ik fout doe?
Wat is langzaam?
Kort gezegd gaat het niet harder dan 85 MB/s sequentieel schrijven (waar ik 400 MB/s of hoger verwacht). Sequentieel lezen gaat redelijk, met ongeveer 435 MB/s (waar ik ongeveer 500 MB/s verwacht).
Als ik een simpele file uit cache van ander filesystem cache naar de SSD schrijf, zie ik dit met 2-second averages in iostat:
sda device rapporteert dus 100% utilisation met slechts 80 MB/s schrijven en een gigantische queue. Hele systeem lijkt ook te bevriezen, alles dat leesacties vereist hangt makkelijk tientallen seconden. Het "tussendoor" lezen lijkt dus niet mogelijk.
Situatie
Ubuntu 15.04 (Linux 3.19, inclusief laatste updates die MU02 weer uit de blacklist haalt, Linux 4.0.4 ook geprobeerd).
LUKS/dm-crypt full-disk-encryption met LVM eroverheen.
GPT partitietabel
UEFI boot
Dell Latitude E7240, laatste BIOS A14 (downgrade geen optie want keyboard issues in Linux).
Wat heb ik allemaal geprobeerd?
1) Firmware update
MU02 verhelpt wel een TRIM-NCQ probleem waardoor de NCQ blacklist in de Linux kernel nu alleen nog geldt voor de MU01 firmware. Ik heb gedubbelcheckt dat ik een nieuwe kernel draai, (4.0.4) waar deze fix in zit.
2) NCQ queue type & depth
depth staat default op 31, dat is prima, type staat op none.
Een queue type op none vind ik verdacht; op internet lees ik dat het 'simple' hoort te zijn. Helaas, kan het niet aanpassen:
3) Check hardware initialisatie
Ziet er goed uit volgens mij, NCQ lijkt te worden ondersteund.
En ook de link speed is goed, 6Gbps:
4) Andere SSD
Samsung SSD geleverd bij Dell is wel rammend snel. Ruim 400 MB/s schrijven. Heb helaas deze SSD niet meer in bezit en niet onthouden wat de queue_type was.
5) Windows proberen
Nog niet gedaan, is me nog even te veel werk. Kan het wel doen, heb een recovery image van Dell op flash drive.
Kennis heeft exact dezelfde laptop en SSD, met Windows, heeft ook soortgelijke prestatieproblemen. Sequentiële schrijfsnelheden variëren erg sterk in zijn geval. Ver onder prestaties zoals getoond in benchmarks/tests online.
6) TRIM aan/uit
Lijkt me sterk dat het gebruik van TRIM invloed heeft op een amper gebruikte SSD; er zijn nog amper pages beschreven namelijk. Ik wil TRIM ook helemaal niet aan, want daarmee lek je informatie naar de dm-crypt/LUKS layer over welke pages onbeschreven zijn.
Toch geprobeerd met de discard/nodiscard parameter in fstab. Geen effect.
7) SSD secure erase
Heeft niets opgeleverd.
8 ) BIOS opties
Kan voor SATA devices instellen in welke SATA mode ze moeten. Legacy, AHCI, RAID (Intel Rapid Storage). Staat op AHCI zoals het hoort.
Laatste BIOS update staat erop. A14 van de E7240.
9) SMART data
Niks bijzonders. 96 uren pas gebruikt. alle tests staan op PASSED.
10) Writeback cache aan/uit
Met hdparm kan de writeback cache aan/uit worden gezet.
Staat standaard aan, uitgezet. WOW:
BAM! 300+ MB/s. Opgelost zou je zeggen? Nee, want nu is random write met kleine files rammend langzaam.... Bijvoorbeeld een kernel update met headers uitpakken duurt nu meerdere minuten daar waar het een paar seconden was met een Samsung SSD.
Zet ik writeback terug aan, blijft het snel...
Lijkt dus werkelijk iets te zijn met een write queue die de performance behoorlijk onderdrukt maar goed wordt gereset met hdparm. Schiet mij maar lek...
Hieronder even uiteengezet wat de situatie is, wat ik gemeten heb. Heeft iemand een idee wat ik fout doe?
Wat is langzaam?
Kort gezegd gaat het niet harder dan 85 MB/s sequentieel schrijven (waar ik 400 MB/s of hoger verwacht). Sequentieel lezen gaat redelijk, met ongeveer 435 MB/s (waar ik ongeveer 500 MB/s verwacht).
Als ik een simpele file uit cache van ander filesystem cache naar de SSD schrijf, zie ik dit met 2-second averages in iostat:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 973.00 0.00 16.50 0.00 80576.00 9766.79 84.65 1612.97 0.00 1612.97 60.61 100.00 sda3_crypt 0.00 0.00 0.00 1014.00 0.00 207556.00 409.38 1642.85 208.60 0.00 208.60 0.99 100.00 crucialmsata-rootfs 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 crucialmsata-homes 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 crucialmsata-bulkdata 0.00 0.00 0.00 325.00 0.00 204800.00 1260.31 550.37 650.82 0.00 650.82 3.08 100
sda device rapporteert dus 100% utilisation met slechts 80 MB/s schrijven en een gigantische queue. Hele systeem lijkt ook te bevriezen, alles dat leesacties vereist hangt makkelijk tientallen seconden. Het "tussendoor" lezen lijkt dus niet mogelijk.
Situatie
Ubuntu 15.04 (Linux 3.19, inclusief laatste updates die MU02 weer uit de blacklist haalt, Linux 4.0.4 ook geprobeerd).
LUKS/dm-crypt full-disk-encryption met LVM eroverheen.
GPT partitietabel
UEFI boot
Dell Latitude E7240, laatste BIOS A14 (downgrade geen optie want keyboard issues in Linux).
Wat heb ik allemaal geprobeerd?
1) Firmware update
MU02 verhelpt wel een TRIM-NCQ probleem waardoor de NCQ blacklist in de Linux kernel nu alleen nog geldt voor de MU01 firmware. Ik heb gedubbelcheckt dat ik een nieuwe kernel draai, (4.0.4) waar deze fix in zit.
# cat /sys/block/sda/device/rev MU02
2) NCQ queue type & depth
depth staat default op 31, dat is prima, type staat op none.
# cat /sys/block/sda/device/queue_{depth,type} 31 none
Een queue type op none vind ik verdacht; op internet lees ik dat het 'simple' hoort te zijn. Helaas, kan het niet aanpassen:
# echo simple > /sys/block/sda/device/queue_type -su: echo: write error: Invalid argument
3) Check hardware initialisatie
# dmesg | grep -i ncq [ 0.983559] ahci 0000:00:1f.2: flags: 64bit ncq ilck stag led clo only pio slum part sxs deso sadm sds apst [ 1.656740] ata2.00: 1000215216 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Ziet er goed uit volgens mij, NCQ lijkt te worden ondersteund.
En ook de link speed is goed, 6Gbps:
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata2.00: supports DRM functions and may not be fully accessible ata2.00: ATA-9: Crucial_CT512M550SSD3, MU02, max UDMA/133 ata2.00: 1000215216 sectors, multi 16: LBA48 NCQ (depth 31/32), AA ata2.00: supports DRM functions and may not be fully accessible ata2.00: configured for UDMA/133 ata2.00: Enabling discard_zeroes_data ata2.00: Enabling discard_zeroes_data ata2.00: Enabling discard_zeroes_data
4) Andere SSD
Samsung SSD geleverd bij Dell is wel rammend snel. Ruim 400 MB/s schrijven. Heb helaas deze SSD niet meer in bezit en niet onthouden wat de queue_type was.
5) Windows proberen
Nog niet gedaan, is me nog even te veel werk. Kan het wel doen, heb een recovery image van Dell op flash drive.
Kennis heeft exact dezelfde laptop en SSD, met Windows, heeft ook soortgelijke prestatieproblemen. Sequentiële schrijfsnelheden variëren erg sterk in zijn geval. Ver onder prestaties zoals getoond in benchmarks/tests online.
6) TRIM aan/uit
Lijkt me sterk dat het gebruik van TRIM invloed heeft op een amper gebruikte SSD; er zijn nog amper pages beschreven namelijk. Ik wil TRIM ook helemaal niet aan, want daarmee lek je informatie naar de dm-crypt/LUKS layer over welke pages onbeschreven zijn.
Toch geprobeerd met de discard/nodiscard parameter in fstab. Geen effect.
7) SSD secure erase
Heeft niets opgeleverd.
8 ) BIOS opties
Kan voor SATA devices instellen in welke SATA mode ze moeten. Legacy, AHCI, RAID (Intel Rapid Storage). Staat op AHCI zoals het hoort.
Laatste BIOS update staat erop. A14 van de E7240.
9) SMART data
Niks bijzonders. 96 uren pas gebruikt. alle tests staan op PASSED.
10) Writeback cache aan/uit
Met hdparm kan de writeback cache aan/uit worden gezet.
Staat standaard aan, uitgezet. WOW:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 329.00 1.50 191.50 6.00 322202.00 3338.94 66.74 260.57 24.00 262.42 4.66 90.00 sda3_crypt 0.00 0.00 1.50 584.50 6.00 346372.00 1182.18 274.50 330.89 24.00 331.68 1.56 91.60 crucialmsata-bulkdata 0.00 0.00 0.00 564.00 0.00 346292.00 1227.99 272.31 343.64 0.00 343.64 1.61 90.60
BAM! 300+ MB/s. Opgelost zou je zeggen? Nee, want nu is random write met kleine files rammend langzaam.... Bijvoorbeeld een kernel update met headers uitpakken duurt nu meerdere minuten daar waar het een paar seconden was met een Samsung SSD.
sda 0.00 1.50 1.00 433.50 4.00 10.00 0.06 0.97 2.22 0.00 2.23 2.20 95.80 sda3_crypt 0.00 0.00 1.00 435.00 4.00 10.00 0.06 0.97 2.22 0.00 2.22 2.20 95.80 crucialmsata-rootfs 0.00 0.00 0.00 432.00 0.00 0.00 0.00 0.96 2.22 0.00 2.22 2.22 95.80
Zet ik writeback terug aan, blijft het snel...

Lijkt dus werkelijk iets te zijn met een write queue die de performance behoorlijk onderdrukt maar goed wordt gereset met hdparm. Schiet mij maar lek...
[ Voor 22% gewijzigd door gertvdijk op 30-05-2015 20:24 ]
Kia e-Niro 2021 64 kWh DynamicPlusLine. See my GitHub and my blog for articles on security and other stuff.