WD SN850 dålig firmware / TLC-implementation?

Samsung var först med TLC och också först med att köra huvudet i problemet - alla andra tittade och lyssnade och lärde sig av Samsungs misstag - men kanske inte fullt ut eller att gamla problem blir som nya igen.

Har du kollat att TRIM verkligen används på lagringen - körs inte den av olika orsaker så kan det förklara din upplevelse (windows kör TRIM normalt när den raderar filer och en fullsvep på all ledig plats i filsystemet en gång i veckan - söndagar om jag mins rätt).

saker som gör att TRIM/unmap inte aktiveras (utan hjälp av drivrutiner) är tex. om du har lagringen i RAID1 på moderkortet då det inte längre är en AHCI-enhet i det läget och då skickas inga TRIM-kommandon.

Det är många enterprise-SSD som gått ut på begagnatmarknaden för spottstyver för att de blivit jättetrötta och grundorsaken har varit att använda OS och använda diskkontroller inte förmedlar TRIM/unmap/discard-kommandon och de emulerade logiska volymer i diskkontrollerna säger att det är en SATA-disk av snurrtyp och då tycker windows inte att några TRIM-kommandon skall skickas, medans hade de emulerade diskarna redovisat sig som SCSI-disk så hade unmap skickats av windows men då är problemet istället att då kan inte windows boota på lagringen då den förstår bara int-13 enheter eller AHCI-enheter och man glömmer att peta in drivrutiner i UEFI som emulerar en int13-enhet/UEFI på SCSI-lagringen under boot-processen...

Med andra ord kontrollera först att TRIM/unmap verkligen skickas av windows till lagringen och gör den inte detta så är det du ser troligen sekundära effekter av att TRIM/unmap inte är körd på mycket länge.

om linux (tex ubuntu-live) startad på en bootbarUSB-sticka, monterar lagringen och sedan gör en "fstrim -v /media/disken" - vilket kan ta ett tag om det inte är gjort på mycket länge och sedan omstartad till windows igen senare, upplever lagringen snabbare och jämnare så är det troligen problem med TRIM inte sänds som är boven till dina upplevda prestandanedsättningar efter en tids användning.

Alla säger 840EVO-fadäsen - men det var den första generationen TLC-celler som gick ut i produkter och med beteende man inte sett förr (eller snarare inte ville se hos dom som tog fram den generationen minne) och ändå till slut fick den acceptabel även om det inte var perfekt lösning med uppdaterade firmwaror.

Fadäsen är snarare att >10 år senare så upprepar konkurrentfirma inom flash-minnen det igen och inte har lärt sig av historian och försäkrat sig att det inte händer igen! - och här kommer det in en massa ekonomiskt viktade kompromisser och det kanske kompromissades lite för mycket på fel ställe...

Samsung 840EVO kratsade ut kanstanjerna med att ha ett rätt fett ECC-lager ovanpå själva minnneschipens lokala felrättning på chip-nivå och det är relativt få som faktiskt förlorade data. Hur är det med WD SN850 - har den också en mjukvaru ECC-lager som rättar när chipen inte längre klarar det???

SSD som inte har det ger IO-fel och kanske tom. hängningar om den här 'decline' av gammal statisk data har gått för långt.

Även om man kopierar och flytta filer för att dess 'flash-del' skall bli motionerad så är det väldigt svårt att motionera så att det garanterar gäller hela diskens metadata - väldigt mycket där är statiskt och aldrig rörs där sedan filsystemet skapades.

Det enda filsystemet som jag vet kan flytta på rubbet samtidigt som disken används som tex. OS-systemdisk är på BTRFS och då med 'balance'

De flesta andra varianter av filsystem behöver att utifrån med en diskimage-program (clonezilla mfl. som 'dd/ddrescue under linux startad med USB-sticka) läsa ut hela diskimage som en diskimage-fil och sedan skriva tillbaka igen - jag vet att det fins program som 'diskfresh och liknande som kan puttra runt och göra det på sektornivå - men vet inte om det också gör det på diskens metadata [läs $MFT om det är windows och på NTFS-filsystem] då de flesta som skiver dyliga program är livrädda att peta i det för att inte riskera att man orsakar korruption av filsystemet när det används hos för många kunder.

De flesta defragmenterinsgprogram använder i slutet Windows egna API i siste steget mot filsystemet för att flytta runt data inom NTFS-filsystemet - men få/inga av dem petar i $MFT och ofta också som program med 'bara' adiminstratörs-rättigheter heller inte kan då OS spärrar för det och att rota där är att såga i grenen man sitter på...

840 fick också en fix, men den kom senare än den för 840 EVO.

840 var väl inte lika illa drabbad som 840 EVO eftersom den använde 21nm NAND istället för 19nm som EVO, så det blev EVO som fick mest uppmärksamhet. Men ändå rätt dåligt att det tog mer än ett år innan Samsung även fixade 840.

Kör mina i RAID 0 på x570. Nån som kan säga om det är bra värden?

Låter verkligen som en EVO 840-sjuka fast nu över 10 år senare och tillverkarna borde ha lärt sig Samsungs läxa och inte upprepa misstagen

Min visade ju bra siffror i CDM trots att den har problem, så du får nog testa med något annat.

Vet inte hur man bäst lästestar filer i Windows, någon får gärna komma med tips! Något som bara läser en fil utan att spara det någonstans, annars blir ju målenheten sannolikt en flaskhals.
Skulle vilja testa detta hos en kompis också, om möjligt helst utan att installera något.

@Fogelholk 842 MB/s och 1 GB/s är nog egentligen lite klent på en sån här disk om inget annat flaskhalsar (typ NTFS-3G), men det är ju snabbt nog att man inte lär märka något.

Jag tog och skrev om allt innehåll på disken. Bootade från en Linux-USB och körde dd if=/dev/nvmeXn1 of=/dev/nvmeXn1 bs=4M status=progress conv=notrunc (med samma X alltså, i mitt fall 0)

Snitthastighet på det blev 582 MB/s. Kollade även hastigheten live lite då och då, och som lägst var den nere på omkring 64 MB/s (190 MB läst på 3 sekunder)!
Typ en timme efter att den blivit klar skrev jag om första 30 GB:en igen som snabbt test, 1.4 GB/s blev det där.

Sen startade jag Windows igen och körde om de test jag körde innan omskrivningen
Alla filer jag testade var stora, så alla borde gå i hög snitthastighet. Den minsta var 6.2 GB.

Så nog jäklar gör det skillnad, till och med REJÄLT märkbart skillnad i att ladda in Horizon, så det är ju inte något som bara märks när man sitter och tar tid heller.
Oklart varför fil #4 gick långsammare än de övriga även efter (2.8 GB/s vid omtest), men nog nöjer jag mig men den farten.

Edit: Kan tillägga att min andra SSD (Kingston NV1) verkar ha samma problem den med... ska ta och skriva om den också senare och se.
En ny fil (max en månad) går i 1.6 GB/s, flera andra också 1.6-1.8 GB/s, men några av de äldsta filerna jag kan minnas (sparade Nov 2021) går i 264 MB/s, 280 MB/s och 606 MB/s. Oklart varför det är så stor skillnad, de tre bör vara skrivna samma dag.

Gnome-disks i ubunu kan göra samma karta över hastigheten som HD-tune och kommer dessutom ihåg plottarna för var disk som testats - en nackdel är att den kan inte testa mer än 1 GB per svep och max 1000 testpunkter vilket gör att det går inte tt testa mer än 1 TB disk om man skall skanna hela diskytan och vid storlekar över det blir det luckor mellan teststripen - en idiotisk begränsning som förmodligen enkelt skulle kunna ändras. Den kan både skriva och läsa (med en viss risk) men skrivning endast på diskar som inte har monterade partitioner - dvs systemdisken som OS kör på kan inte testas i avseende skrivhastighet.

Att skriva till NTFS (3g-NTFS) är ingen hit i Linux - dels för att det är fuse-system och mycket transaktioner mellan user och kärndomain med mycket overhead - och att vart fall $MFT hanteringen också körs enkeltrådat i Userdomänen (det gör det också i windows men det döljs väl) vilket märks mest om man skapar och kör väldigt många småfiler.

På den relativt nya linuxinstallationen medn kernelstöd för NTFS har det vart fall gått upp från ~100 MB/s till nu runt 380 MB/s vid en första zerofill-skrivning-fil av ca 96 GB på NTFS på en NVMe och det hoppar upp och ned ganska ordentligt till under 200 MB/s och luktar att det är NVMe som bromsar (utrymmet i NTFS har inte omsatts på länge) det är ingen märkvärdig NVMe utan medföljande SKHynix_HFM512GDHTNI i laptopen

Andra körningen så studsade värdena upp till drygt 700 MB/s i topparna men fortfarande ganska låg genomsnittshastighet (för att vara NVMe) som ändå höjts från ca 480 MB/s till 668 MB/s - så det tyder på att det är NVMe som fortfarande flaskar och inte NTFS-filsystemhanteringen.

tredje körningen ligger nu på 710 MB/s hela vägen och där verkar det landa och blir inte så mycket högre även om man fortsätter skrivcyklingen - dock i början av skrivningen så ser man värdena > 1000 MB/s skrivet mot lagringen men sedan flaskar det fort ned till runt 710 MB/s och det är 101% upptaget mot själva lagringen, så jag tolkar att det är lagringen som fortfarande flaskar och inte filsystemet.

fick samma värden när jag körde mot ext4 där första zerofill också gick långsamt i området 300-400 MB/s (snabbare än NTFS men så är utrymmet mer omsatt) och därefter ett par skrivvarv/TRIM-körning stannade på ca 710 MB/s förutom inledande burst på drygt 1000 MB/s. Vid läsning så låg båda på runt 1060 MB/s och ingen skillnad mellan NTFS och ext4 och farten verkar vara helt lagringsstyrt.

I det här fallet vid första körning på ext4 så avbröt jag halvvägs när det låg och pendlade mellan 300-400 MB/s - körde en 'fstrim -v .' - väntade en kort stund efter för att NVMe skulle ha en chans att städa upp och skrev igen och nu såg inget av någon trappsteg i fart utan låg på ca 710 MB/s hela vägen.

TRIM/Discard och att dessa körs då och då har betydelse för skrivhastigheten...

hur eller hur får man säga att skrivning mot NTFS i linux har förbättrats avsevärt mot tidigare med 3g-NTFS med dom senaste versionerna av Ubuntu, däremot är inte Hynix-NVMe direkt någon klar lysande stjärna i fart här...

Dock till min förvåning fungerar inte fstrim längre på NTFS-partitionen fast det är intern lagring på datorn, det gjorde det med äldre ubuntu-installationen - har det något att göra med att man bytt NTFS-drivrutin i Linux och stödet för TRIM ännu inte följt med ???

Trim är viktig och också konstatera att skrivhastigheten på utrymmen i SSD/NVMe med gammal data kvar och de fått lite ålder på sig (dvs har inte körts TRIM på) kan tröga ned skrivningen ordentligt och så lågt som 200 MB/s som jag såg ibland i första körningen på NTFS-delen i burken...

---

Vet inte om det går att forcera 'TRIM' i Windows för att städa upp all ledig diskutrymme i filsystemet på samma sätt som man gör med 'fstrim' i Linux utöver det som sker automatiskt när fler raderas.

Optimize-Volume -DriveLetter C -ReTrim -Verbose

Det går nog i GUI också, "Defragment and Optimize Drives" heter programmet på engelska. Optimize verkar vara TRIM.

Fins det ingen enkel och lättbegriplig kommando liknande 'fstrim' i windows istället för att skriva en hel mening i powershell så fort något skall göras!?. kommer man från Linux/unix med korta och effektiva kommando så upplever man mycket som att dra mothårs i powershell för att göra samma sak...

Jag kommer ihåg tidigare att få fram en hashsumma liknande som med 'sha1sum' på en inslagen textträng direkt efter i kommandoraden var helt löjligt komplicerad i powershell, men lite bit enklare om samma text var lagd i en fil.

https://learn.microsoft.com/en-us/powershell/module/microsoft...

$stringAsStream = [System.IO.MemoryStream]::new()
$writer = [System.IO.StreamWriter]::new($stringAsStream)
$writer.write("Hello world")
$writer.Flush()
$stringAsStream.Position = 0
Get-FileHash  -Algorithm SHA1 -InputStream $stringAsStream | Select-Object Hash

Lite

över det där...

Halvt OT här (inte om SN850), men om exakt samma problem.

Alltså... jag tog och skrev om allt på min Kingston NV1 också, varför inte liksom.
Det tog en förjäkla lång tid, snitthastigheten blev omkring 130 MB/s, så drygt 4 timmar.

Hastigheten var upp till typ 800-900 MB/s (tänk på att den läser och skriver till samma enhet här), men som lägst var den ner UNDER 1 MB/s i snitt över flera sekunder!
Att den låg omkring 13-15 MB/s var inte alls ovanligt.

Jag undrar lite om det var det tomma utrymmet som var långsammast att läsa -- områden som kanske inte ens skrivits sedan disken var ny (jag köpte den Nov 2021). Eftersom jag körde med dd så bryr den sig inte om vad som är använt eller ledigt, den förstår inte ens skillnaden.
Tyvärr så kan jag nog aldrig få veta det.

Jag loggade hastigheten var 5:e sekund och gjorde en scatter plot:

Det är ju väääldigt många punkter längst ner där, långt under 50 MB/s...
Började logga en stund efter förresten, så jag räknade bakifrån och placerade den så den slutar där disken slutar. X-axeln är lite knasig enhet (miljoner MiB) men det spelar väl ingen större roll, positionen är inte exakt oavsett.

Efter omskrivningen är den också snabb nu igen åtminstone, runt 1.8 GB/s konstant nu.

@filbunke

@Thomas

hur ser det ut vid andra körningen - efter att ha 0-fyllt hela lagringen (om du kan och inte har det som systemdisk - om du inte kan - kör fstrim om det är linux fs och eventuellt också NTFS först om det nu fungerar efter att man gick ifrån 3g-NTFS - annars får du göra det i windows enligt tidigare inlägg hur man gör det i powershell)

ibland kan man fräscha upp det hela med att göra en diskimage av disken från LBA 0 till LBA slut och sedan ladda tillbaka det igen från lagringen som höll diskimagen - eventuellt med en '0' skrivning mellan så att en tillbakaskrivning verkligen resulterar i en flash-skrivning och inte märker att datat är redan på plats och skiter att skriva om. - gnome-disks har en sådan funktion i sina 3-punkter meny om man inte själv vill kladda med 'dd' - och den stänger också filsystemen på disken innan den gör diskimagen - vilket är lätt att glömma bort när man själv gör image med 'dd'

Sådär fick man göra med Samsung 840 EVO om man ville ha full fart på de lästa filerna i filsystemet - även efter firmware uppdateringar då det kunde bli rätt långsamt innan det fräschade upp filerna igen.

Efter omskrivning var alla i princip samma hastighet, gjorde ingen graf för det hade varit en rak linje
Lägsta värdet var 1128 MB/s, högsta 1158 MB/s. Orkade inte vänta på hela disken men jag körde igenom 7 minuter, så typ 460 GB.

Jag körde dd för att skriva om direkt (if= och of= på samma) istället för att lägga på en tillfällig plats, det funkar fint.

Prestandan verkar påverkas mätbart på en vecka eller två, inte direkt lovande.

Rad 1 är före omskrivning av all data, rad två+tre strax efter (med reboot mellan), sedan är det bara lästest en gång per vecka.
Varje kolumn är snitthastighet på att läsa in en specifik fil, så t ex kolumn 1 är alltid samma fil, kolumn 2 alltid samma fil osv.

serenity@NEUTRON:~/ssd-bench $ cat sn850-speeds.txt
Date/time               Speeds
2023-08-19 23:00        156 MB/s        172 MB/s        2.7 GB/s        2.7 GB/s        # före omskrivning av disken
2023-08-20 11:48        4.1 GB/s        4.1 GB/s        3.0 GB/s        4.1 GB/s        # efter omskrivning av disken
2023-08-20 18:26        4.1 GB/s        4.2 GB/s        3.0 GB/s        4.1 GB/s
2023-08-27 09:00        3.8 GB/s        3.9 GB/s        2.9 GB/s        4.0 GB/s
2023-09-03 09:25        3.4 GB/s        3.1 GB/s        2.3 GB/s        3.2 GB/s
2023-09-10 08:50        2.5 GB/s        3.0 GB/s        2.8 GB/s        3.9 GB/s
2023-09-17 08:58        1.4 GB/s        1.4 GB/s        3.2 GB/s        3.3 GB/s
2023-09-17 11:09        4.2 GB/s        4.2 GB/s        3.1 GB/s        4.0 GB/s        # efter omskrivning kl 10

Motsvarande siffror för min Kingston NV1, dock med en skillnad: första testet är före omskrivning, andra testet också utan omskrivning men efter reboot, och tredje och senare är efter omskrivning.

Intressant nog verkar SSDn ha optimerat datan pga enbart läsning, eftersom rad 2 är klart bättre än rad 1. Kanske märkte den av att den hade problem att läsa och fräschade upp vissa block?

serenity@NEUTRON:~/ssd-bench $ cat nv1-speeds.txt
Date/time               Speeds
2023-08-20 12:05        280 MB/s        606 MB/s        1.8 GB/s        1.8 GB/s        # första testet
2023-08-20 12:17        750 MB/s        1.3 GB/s        1.8 GB/s        1.8 GB/s        # UTAN omskrivning, bara reboot
2023-08-20 18:26        1.8 GB/s        1.8 GB/s        1.8 GB/s        1.8 GB/s        # efter omskrivning
2023-08-27 09:00        1.6 GB/s        1.6 GB/s        1.4 GB/s        1.7 GB/s
2023-09-03 09:25        1.7 GB/s        1.8 GB/s        1.7 GB/s        1.7 GB/s
2023-09-10 08:37        1.7 GB/s        1.8 GB/s        1.8 GB/s        1.7 GB/s
2023-09-17 08:58        1.8 GB/s        1.8 GB/s        1.8 GB/s        1.8 GB/s
2023-09-17 11:09        1.8 GB/s        1.8 GB/s        1.8 GB/s        1.8 GB/s        # ingen omskrivning, enbart SN850 ändrades

Edit: Bör också nämna att kolumnerna är i ungefärlig kronologisk ordning, dvs de till vänster är filer som sannolikt har legat längre, medan de till höger är nyast.
Detta spelar nog ingen roll efter omskrivningen dock, men har stor påverkan före, när viss data var 2-3 veckor gammal och viss data över ett år.

EDIT: Uppdaterade alla siffrorna 2023-09-17. Skrev om på SN850 igen då jag tyckte 1/3 av prestandan på vissa filer var lite klent...

Oroväckande siffror. Kan detta påverka deras nuvarande modell (SN850X) också? Satt just och kollade på om man skulle beställa en sådan.