Långsam skrivning till Seagate FireCuda 520 SSD m.2

Permalänk
Medlem

Långsam skrivning till Seagate FireCuda 520 SSD m.2

Tjena! Märkte när jag testade lite benchmarks häromdagen att skrivprestandan var extremt låg på min huvud-SSD, nämligen Seagate FireCuda 520 2 TB.

Här kommer lite bilder

Benchmark från ATTO Disk
https://imgur.com/a/AFFn55u

Seagate
https://imgur.com/DQU7A52

Benchmark från CrystalDiskMark
https://imgur.com/hBQQly9

Har senaste firmwaren (uppdaterade men hjälpte ej). Enheten är formaterad med cluster på 4 KB.

Min andra m.2-disk som är en Samsung 970 EVO 1 TB har bättre skrivprestanda.

Permalänk
Moderator
Festpilot 2020, Antiallo
Skrivet av iRonNuke:

Tjena! Märkte när jag testade lite benchmarks häromdagen att skrivprestandan var extremt låg på min huvud-SSD, nämligen Seagate FireCuda 520 2 TB.

Här kommer lite bilder

Benchmark från ATTO Disk
https://imgur.com/a/AFFn55u

Seagate
https://imgur.com/DQU7A52

Benchmark från CrystalDiskMark
https://imgur.com/hBQQly9

Har senaste firmwaren (uppdaterade men hjälpte ej). Enheten är formaterad med cluster på 4 KB.

Min andra m.2-disk som är en Samsung 970 EVO 1 TB har bättre skrivprestanda.

Ja, det där var riktigt horribla hastigheter.
Ska väl vara en klassisk Phison PS5016-E16 med en duglig cache så den ska vara snabbare.
Har du låtit disken vila så att RAM-cache och eventuell Psudo-SLC cache har fått tömmas innan test?

Visa signatur

 | PM:a Moderatorerna | Kontaktformuläret | Geeks Discord |
Testpilot, Skribent, Moderator & Geeks Gaming Huvudadmin

Permalänk
Medlem

Kollat att TRIM/discard fungerar ???

Är lagringen satt tex. i RAID under BIOS så kör inte windows någon TRIM/discard mot lagringen när filer raderas - och det kan göra flash-minnen långsamma med tiden.

Windows kör bara TRIM om lagringen är av AHCI-typ (läs SATA-diskar) eller är SCSI-typ (som iSCSI eller NVMe) medans en BIOS-RAID eller en HBA-RAID ger bara logiska volymer som inte kan identifieras som fysiska diskar, och därför kör windows ingen TRIM mot dessa även om den bakomliggande lagringen bara består av flash-lagring...

Har du dessutom fyllt disken knökfull med data, så är poolen med för-raderade flash-block för snabb skrivning väldigt liten (kanske nere på 1-2% av lagringens volym) och du kommer snabbare märka att flash-lagringen inte har de skrivhastigheter som förväntas längre - och tyvärr hjälper det inte att radera filer i det läget om windows TRIM inte arbetar när filer raderas.

Permalänk
Medlem
Skrivet av xxargs:

Kollat att TRIM/discard fungerar ???

Är lagringen satt tex. i RAID under BIOS så kör inte windows någon TRIM/discard mot lagringen när filer raderas - och det kan göra flash-minnen långsamma med tiden.

Windows kör bara TRIM om lagringen är av AHCI-typ (läs SATA-diskar) eller är SCSI-typ (som iSCSI eller NVMe) medans en BIOS-RAID eller en HBA-RAID ger bara logiska volymer som inte kan identifieras som fysiska diskar, och därför kör windows ingen TRIM mot dessa även om den bakomliggande lagringen bara består av flash-lagring...

Har du dessutom fyllt disken knökfull med data, så är poolen med för-raderade flash-block för snabb skrivning väldigt liten (kanske nere på 1-2% av lagringens volym) och du kommer snabbare märka att flash-lagringen inte har de skrivhastigheter som förväntas längre - och tyvärr hjälper det inte att radera filer i det läget om windows TRIM inte arbetar när filer raderas.

Kollade med kommandot fsutil och det gav ett resultat som sa att det var aktiverat. Körde sedan ett litet program som heter trimcheck-0.7-win64.exe. Den upptäckte att den inte kunde aktivera trim när komprimering var aktivt(wot!).

Efter att jag inaktiverat filkomprimering (har nog råkat aktivera det när disken var full och Windows ville ge mig utrymme)

Samt ytterligare tömt disken lite grann.

https://imgur.com/1zBKpYR

https://imgur.com/X0BGuyO

Tack för hjälpen hursomhelst.

Permalänk
Medlem

Det var en ny faktor i winvärlden som tydligen stänger av TRIM utan att man vet om det eller något som talar om det när det sker... - och med tanke på hur windows hanterar komprimerade filer och den massiva fragmentering som sker där så är det kanske inte så konstigt...

Permalänk
Moderator
Festpilot 2020, Antiallo
Skrivet av iRonNuke:

Kollade med kommandot fsutil och det gav ett resultat som sa att det var aktiverat. Körde sedan ett litet program som heter trimcheck-0.7-win64.exe. Den upptäckte att den inte kunde aktivera trim när komprimering var aktivt(wot!).

Efter att jag inaktiverat filkomprimering (har nog råkat aktivera det när disken var full och Windows ville ge mig utrymme)

Samt ytterligare tömt disken lite grann.

https://imgur.com/1zBKpYR

https://imgur.com/X0BGuyO

Tack för hjälpen hursomhelst.

Jag ger dig en guldmedalj som kommer tillbaka och delar med dig av lösningen. 🥇🥇🥇
Vi behöver fler hjältar som dig!

Visa signatur

 | PM:a Moderatorerna | Kontaktformuläret | Geeks Discord |
Testpilot, Skribent, Moderator & Geeks Gaming Huvudadmin

Permalänk
Medlem
Skrivet av DavidtheDoom:

Jag ger dig en guldmedalj som kommer tillbaka och delar med dig av lösningen. 🥇🥇🥇
Vi behöver fler hjältar som dig!

Har många gånger tänkt att synd att en del som har löst det kanske skriver att de har löst det, eller inte återkopplat alls. Men kan ju vara bra ifall någon annan får problem, hur eller vad som var fel tänkte jag