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.

Jag har märkt av samma sak på min WD SN850 1TB (firmware 613200WD). Märkte av det redan för ett år sedan och försökte hitta om andra hade råkat ut för samma sak. Tyvärr hittade jag ingen då.

I juni 2022 köpte jag en ny OS-disk (Kingston KC3000 2 TB) och började använda WD-disken för spel. Det gjorde också att jag nu, 6+ månader senare, kan få lite bättre statistik för hur en fils ålder påverkar läshastigheten.

Jag har använt mig av SSDReadSpeedTester2.04 från den här tråden på overclock.net. Det programmet användes av många då Samsung hade problem med 840 EVO.

Bifogar output från SSDReadSpeedTester samt två figurer från Matlab där jag kört boxchart på filer ">300 MB" respektive ">600 MB".

<Uppladdad bildlänk>
<Uppladdad bildlänk>
<Uppladdad bildlänk>

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