WD Green M.2 SSD enorm traag icm een AMD Athloon 3000G

[Rainbow]

Om een SATA poort vrij te maken op mijn moederbord voor een hard disk, ben ik mijn 2.5" SATA SSD (een best wel oude Crucial M4) aan het vervangen voor een M.2 SATA SSD: pricewatch: WD Green SSD M.2 V2 120GB

Volgens verschillende reviews en informatie op het internet hoort die redelijk snel te zijn, zowel lezen als schrijven. Echter nu ben ik in Linux wat testjes aan het doen met `dd`.... en hij is echt dramatisch traag met het schrijven.

Ter vergelijking (1GB sequentieel):

SSD	Lezen	Schrijven
Crucial M4	~465 MB/s	~115-180 MB/s (geen idee waarom het zo fluctueert)
WD Green	~420 MB/s	~20 MB/s

Nu heb ik nog vrij weinig verstand van M.2 en AMD, maar in het boekje van het moederbord las ik dat de 4x SATA aangestuurd worden door de chipset, terwijl de compatibility van het M.2 slot afhangt van de CPU. Dus dan trek ik de conclusie dat die SSD dus ook door de CPU aangestuurd wordt. Klopt dat?

In deze computer zit:
- Moederbord: pricewatch: Asus Prime A320I-K/CSM
- CPU: pricewatch: AMD Athlon 3000G Boxed

Nu maakt het mij op zich niet zo uit in deze computer als die wat traag is, maar 20 MB/s is wel echt héél erg weinig. Kan dit komen door de CPU of iets? Klinkt dit bekend en zijn work-arounds mogelijk om dit toch werkend te krijgen met deze hardware, of ben ik in de aap gelogeerd?

[ Voor 0% gewijzigd door Rainbow op 05-12-2020 21:04 . Reden: MX->M4 ]

[Rainbow]

Korte follow-up op mijn eigen post, sorry. Ik vond dit: https://old.reddit.com/r/...rite_performance/f00yabg/

[quote]
Thought I would update this since there might be value to others. Yesterday I made time to clone my NVME system disk to the intel raid 0 array, once done I changed the boot order and then perform a full wipe on the NVME ssd, zeroing it out completely. After this from the cloned copy I benched it and the write performance was back to where it should be. After this I cloned the system drive back to the NVME ssd and once done, I benched it again, and again it was still back to where it should be 3400/3000, 1700/1600, 600/550, 50/230 read write respectively for CDM. I'm not sure what changed by simply zeroing the drive out, but it has at least for now fixed the slow writes.
[quote]

Wellicht dat dit een clue is. Ik heb het programmaatje badblocks gebruikt om de SSD te checken. Die schrijft de gehele disk vol met data. Ik kan mij iets herinneren over dat als een SSD helemaal 100% vol zit, de performance enorm keldert. Dus wellicht is dat er aan de hand... Het "vullen" van de SSD met badblocks duurde ook maar 20 minuten, dus met een 120GB disk is dat ~100 MB/s.

Dit had ik mij eerder moeten bedenken. Beetje stom dat ik niet door had dat tijdens deze test de performance dus gewoon helemaal prima was.

Ik ga de disk nu wel eerst even weer zero-en met `dd` en daarna kijken of de performance weer normaal is.

[Renault]

Waarom neem je zo'n kleine SSD? Daar kan je op termijn nauwelijks iets mee (of heeft dat te maken met het gebruiksdoel ervan?).
En van SATA 2,5" naar M2 SATA lijkt mij ook nauwelijks een verbetering.

Waarom "zero" je de SSD? Dat levert een berg onnodige slijtage extra op ....

[ Voor 10% gewijzigd door Renault op 05-12-2020 19:46 ]

[Rainbow]

Renault schreef op zaterdag 5 december 2020 @ 19:45:
Waarom neem je zo'n kleine SSD? Daar kan je op termijn nauwelijks iets mee (of heeft dat te maken met het gebruiksdoel ervan?).
En van SATA 2,5" naar M2 SATA lijkt mij ook nauwelijks een verbetering.

Waarom "zero" je de SSD? Dat levert een berg onnodige slijtage extra op ....

Bedankt voor je suggesties.

- Waarom neem ik zo'n kleine SSD: omdat het voor deze computer alleen gebruikt wordt als boot disk, de bulk opslag zijn mechanische hard disks. De Crucial die erin zit is overigens maar 64GB en was voor slechts 15GB gevuld. Ik ben gegaan voor zo'n beetje de goedkoopste die ik kon vinden.

- Waarom van SATA 2.5" naar M.2: zodat de SATA aansluiting beschikbaar wordt voor een extra mechanische hard disk. Dit moederbord heeft maar 4 SATA aansluiting.

- Waarom "zero" ik de SSD?: wellicht heb ik dat in mijn 2e post niet goed aangegeven. Ik had een run gedaan met "badblocks", dat programma schrijft de schijf vol met een patroon en leest het daarna weer, om te verifiëren dat de schijf goed werkt. In de gelinkte/gequote Reddit post is er iemand met een vergelijkbaar probleem, die aangeeft dat het zero-en het probleem verholpen heeft voor hem. Daarom ben ik dat nu ook aan het proberen.

- Slijtage: volgens mij kunnen moderne SSD vele honderden terabytes aan writes aan. Als ik een "badblocks" met 3 passes uitvoer en daarna 1 zero, dan is dat nog geen 1TB aan writes. Ik heb zelf eigenlijk nog nooit gehoord over een SSD die overleden is aan slijtage (aantoonbaar).

[Uszka]

WD Green 120GB heeft een garantie van 40TBW dus die vele honderden is erg overdreven.

Beter is een Cristaldiskmark uit te voeren als je de prestaties van de schijf wil weten.

[Thralas]

Rainbow schreef op zaterdag 5 december 2020 @ 19:55:
Daarom ben ik dat nu ook aan het proberen.

Niet zerofillen. Het verbaast me dat dat zou helpen, dat impliceert dat iets het magischerwijs als block erase herkent.

blkdiscard /dev/nvmeXn1

Dat discard de hele drive (!) en is de enige juiste manier om dit te doen. Is bovendien vrijwel instantaan.

Als je al een filesystem hebt waar je waarde aan hecht kun je fstrim gebruiken. Die is slim genoeg om alle vrije ruimte van het filesystem te discarden.

Overigens, dubbelcheck even hoe je je filesystems maakt en/of mount, want in ieder geval mkfs.ext4 doet zelf ook al een discard op SSD-partities als het goed is.

[ Voor 14% gewijzigd door Thralas op 05-12-2020 20:29 ]

[Rainbow]

Uszka schreef op zaterdag 5 december 2020 @ 20:19:
WD Green 120GB heeft een garantie van 40TBW dus die vele honderden is erg overdreven.

Beter is een Cristaldiskmark uit te voeren als je de prestaties van de schijf wil weten.

Sorry dat ik een foutje maakte, ik bedoelde het niet verkeerd. Ik dacht oprecht dat het om 100+ ging, maar dat is inderdaad niet juist. Helaas zie het er niet uit dat CrystalDiskMark beschikbaar is op Linux. Wellicht kan ik wel eens KDiskMark uitproberen echter.

Thralas schreef op zaterdag 5 december 2020 @ 20:27:
[...]


Niet zerofillen. Het verbaast me dat dat zou helpen, dat impliceert dat iets het magischerwijs als block erase herkent.

blkdiscard /dev/nvmeXn1

Dat discard de hele drive (!) en is de enige juiste manier om dit te doen. Is bovendien vrijwel instantaan.

Als je al een filesystem hebt waar je waarde aan hecht kun je fstrim gebruiken. Die is slim genoeg om alle vrije ruimte van het filesystem te discarden.

Overigens, dubbelcheck even hoe je je filesystems maakt en/of mount, want in ieder geval mkfs.ext4 doet zelf ook al een discard op SSD-partities als het goed is.

Ja ik dacht inderdaad dat voor een SSD een block met enkel zeroes hetzelfde was als een "discarded" block, maar nu begrijp ik dat dat niet zo is. Bedankt voor de "blkdiscard" tip, die kende ik nog niet. Super handig om snel een hele SSD te wipen. Precies waar ik naar op zoek was voor mijn huidige probleem!


Uiteindelijk was ik gewoon super dom, want de issue lijkt dus echt niets te maken met dat ik de hele schijf opgevuld had via "badblocks". Toen ik wat meer met "dd" bezig was, herinnerde ik mij de "bs" optie om de blocksize aan te passen. Toen ik die op een veel groter getal zette (bijv. 100KB, de default is 512 bytes) ging het schrijven echt enorm veel sneller, richting de 80~100 MB/s.

[Uszka]

In geval van een NVME ssd krijgt die in het M2 slot idd lanes van de cpu maar niet met een Athlon 3000G. Met die cpu is geen NVME mogelijk, alleen sata. Die zal vast wat van de cpu krijgen maar wordt geregeld door de chipset.