Seg/Laggande hårddisk, inga fel enligt diagnostiktester?

Permalänk

Seg/Laggande hårddisk, inga fel enligt diagnostiktester?

Slängde in en WD Black 6 TB som är i princip oanvänd som jag köpt för några år sedan jag tänkte ha som lagring till en filserver, men stött på ett ganska underligt problem med disken, om jag skriver eller läser lite större filer till/från disken så är det som att den tappar 95% av kapaciteten efter ett x antal sekunder gått, för att sedan återfå full kapacitet i ytterligare några sekunder innan det är samma visa igen. Vid en filöverföring till/från disken exempelvis, kan pendla upp och ner från mellan 200+ MB/s ner till några B/s och det är en ren plåga att föra över filer på några GB. Även märkt att om jag packar upp en fil direkt från min OS SSD till denna så verkar uppackning och flyttning från tempmappen fungera utan några konstigheter, men om jag direkt efter uppackning ska döpa om filen jag just packat upp, så hänger sig utforskaren (klassiska ...svarar inte) i upp till en minut innan det går att fortsätta en stund till som om inget har hänt.

Det konstiga är att när jag kört diagnostester (HD Tune, Crystaldiskmark och Parted Magic) så visar alla att det inte skulle vara något fel på disken överhuvudtaget, och läs/skrivhastigheterna i Diskmark verkar ligga normalt om jag jämför med andra diskar i samma maskin, därav jag sliter mig i håret då det är när man använder disken "på riktigt" som jag upplever dessa problem, men kör man ett gäng tester på den så presterar den utan några konstigheter alls

Någon som har nån idé om vad det kan vara? Testat byta ut kablage, byta port på moderkort, provat helt annan sata-kontroller och testat lägga in ett script som ska omöjliggöra att den disken går i viloläge av sig själv, inget av detta har gett något resultat.

Screenshot Crystaldiskmark på WD Black-disken det gäller

Screenshot på en annan disk (WD Red 5400 RPM) som funkar perfekt utan dessa problem

Tack på förhand!

Permalänk
Medlem

S.M.A.R.T data?

Skickades från m.sweclockers.com

Permalänk
Medlem

Hade samma problem med en av mina diskar för någon vecka sedan och de visade sig att jag hade en hel del dåliga sektorer, kanske är något att kolla in om du inte redan gjort de.

Permalänk
Medlem

Gör en skrivning från sektor 0 till sektor slut med med '0' med tex. 'dd' i linux eller en full diskkryptering med tex veracrypt under windows och låt det ta den tiden det tar.

ta SMART-värde före och efter för att se om antalet reallokerade sektorer har ökat efter omskrivningen

När det skriver i SATA-snurrdiskar så verifieras sektorerna direkt strax efter skrivning med en läshuvud precis efter skrivhuvudet och är kvaliten för dålig så upprepas skrivförsöken ett antal gånger och går det ändå inte så reallokeras sektorn. det är endast vid skrivning som det verifieras - En senare läsning av sektor som är vek och dålig kvalitet rättas inte när det gäller SATA-snurrdiskar - sådan görs bara automatiskt i SAS-diskar

När man skriver på detta sätt som ovan så skriver man över sektorerna utan att först läsa i dessa och då heller inte fastnar på svårlästa sektorer med massor av tidsödande läsförsök på var och en av sektorerna...

Efter en sådan varv så är alla sektorer friska och fräscha och det bör inte vara ett problem när du sedan partitionerar upp disken och sedan använder det.

---

Varför det tar tid nu när du försöker skriva beror på att datorn försöker använda filsystemet för att orientera sig så att det skriver på rätt ställe (den delen som håller reda på allt kallas $MFT i NTFS-filsystemet) och är $MFT svårläst och kräver många läsförsök innan korrekt data så får du precis den effekten som du beskriver att det går väldigt långsamt ibland.

---

Det som bekymrar mer är att du överhuvudtaget har den här typen av bekymmer.

Hårddiskskivor designas (i alla fall enligt Seagates utvecklare) för att hålla data intakt i minst 10 år vid den tänkta maxtemperaturen.

dvs. disken skall kunna sitta hot-spare i en varm och dåligt kyld RAID och vid problem kunna börja arbeta direkt även efter 5-7 år och då skall den inte fastna på några svårlästa sektorer eller svårigheter att hitta rätt spår - för om man har svårlästa sektorer så kommer också på disken viktig interndata som sektoradresser, checksummor, ECC, GAP och GAP3 m.m. också vara svårlästa och det är strukturer som aldrig skrivs om sedan disken var tillverkad och det är väldigt tveksamt om det finns recoveryfunktioner som kan rätta sådant i efterhand, utan förmodligen vid enstaka fall omallokeras till reservsektorer.

Dock har jag själv sett på vissa diskar med mycket drifttid där hela disk-skivan verka bli svårläst på en gång efter en längre lagring - dvs har problem med var och varannan sektor oavsett var på skivan. - där kan förvisso vara läshuvudförstärkare eller annat som är utanför sina marginaler och därför läser in så mycket fel och inte att själva skivan har tappat magnetism.

Vet inte om jag kan hitta den (ATA/IDE-disk) eller om den är kasserad - men ett sätt för att kolla är att skriva om disken från första till sista sektorn och se om läshastigheten blir fullgod igen efter och utan att stoppa och stalla - för går det bra efter omskrivning så kan det bero på att skivan tappat magnetism trots allt.

Permalänk
Medlem

Hårddiskar går sönder.. inget konstigt med det

Skickades från m.sweclockers.com

Permalänk
Medlem

Dock finns det ingen anledning att slänga saker som inte är något fel på - och inte helt sällan så är symtomen som visar sig resp. orsaken till problemet helt olika saker - att det stallar periodvis behöver inte ha något alls med disken att göra utan det är något annat i program eller drivrutinväg som är det egentliga problemet.

Ett sätt att prova detta är att starta uppe en linux från en USB-sticka och tex. göra skrivtester med 'dd' mot den monterade disken som man misstänker strul med och se om det stallar på samma sätt - Linux har inga gemensamma drivrutiner med Windows och går det bra med hög och jämnt skrivhastighet under linux, men kackigt under windows så kan man av testet dra slutsatsen att det inte är själva disken eller dess anslutningar som är problemet.

Permalänk

Tack för alla svar hittills. Har mer eller mindre bott på jobbet de senaste dagarna så har tyvärr inte haft möjlighet att svara i tråden tidigare, sitter via telefonen nu så avskriver mig från kommentarer om att jag är lat som inte citerar osv hatar att skriva längre texter på annat än ett fysiskt tangentbord. Har redan kollat efter skadade sektorer samt skrivit random data över hela disken för att testa, inga problem alls. Som jag skrivit innan så verkar inte heller läs/skrivhastighet vara något bekymmer när man kör tester, men så fort jag använder disken "på riktigt", flyttar filer mellan diskar, laddar ner saker till disken osv så märker jag direkt att det inte står rätt till. Att köra en virtuell maskin från disken är direkt omöjligt, samma vm som flyter på hur bra som helst på en långsammare wd red hänger sig stup i kvarten från denna.

Permalänk
Medlem

@Tuborgarn: som sagt, ge oss smartdatan så bör vi kunna ge bättre svar:)

Permalänk
Medlem

Vilken miljö kör du VM i när du har problemet - linux/windows/VMware ? - det framgår inte riktigt vid en snabbare läsning

varför frågan är om problemen är under just en enda OS/VM-miljö eller om samma sak sker under flera OS

Permalänk
Medlem

@Tuborgarn: Är Skrivcachen aktiverad i ditt OS? Prova både med och utan den aktiverad. Observera att det är den skrivcache som finns i ditt OS, inte den inbyggda cachen i disken.

Blir det samma om du kopierar en fil som är bra liten (max 100MB) samt även medel (som ryms i din RAM), samt en rejält stor (mer än 100GB)?

Provat stänga av indexeringen? Den ökänd i Windows för att sega ner datorn. Gör det på alla diskar, även på SSD / M.2.
Stäng även av allt kontraspionage som Windows använder sig av.

Om din systemdisk är en SSD/M.2, rensa ur cache från browsers, tempfiler och papperskorgen och framtvinga en trim på på den disken.

Kolla i enhetshanteraren om du får upp någon varningstriangel för disken.

Kollat att partitionen inte "ligger snett" gentemot diskens fysiska struktur? Detta ses lätt i fdisk i linux samt i gparted.

Skriv också vad maskinen innehåller.

Visa signatur

Server: Fractal design Define 7 XL | AMD Ryzen 7 5800X 8/16 | ASUS ROG CROSSHAIR VIII DARK HERO | 64GB Corsair @ 3000MHz | ASUS Radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2TB Samsung 850 PRO SSD | 6x Seagate Ironwolf Pro 10TB
WS: Phantex Entoo Elite | AMD Ryzen Threadripper 1950X 16/32 | ASUS Zenith extreme | 128GB G.Skill @ 2400MHz | ASUS Radeon HD7970 | 3x 2TB Samsung 960PRO M.2 | 6x Seagate Ironwolf Pro 10 TB
NEC PA301W 30" @ 2560x1600 | Linux Mint 21.3 Cinnamon

Permalänk
Medlem
Skrivet av Tuborgarn:

Slängde in en WD Black 6 TB som är i princip oanvänd som jag köpt för några år sedan jag tänkte ha som lagring till en filserver, men stött på ett ganska underligt problem med disken, om jag skriver eller läser lite större filer till/från disken så är det som att den tappar 95% av kapaciteten efter ett x antal sekunder gått, för att sedan återfå full kapacitet i ytterligare några sekunder innan det är samma visa igen. Vid en filöverföring till/från disken exempelvis, kan pendla upp och ner från mellan 200+ MB/s ner till några B/s och det är en ren plåga att föra över filer på några GB. Även märkt att om jag packar upp en fil direkt från min OS SSD till denna så verkar uppackning och flyttning från tempmappen fungera utan några konstigheter, men om jag direkt efter uppackning ska döpa om filen jag just packat upp, så hänger sig utforskaren (klassiska ...svarar inte) i upp till en minut innan det går att fortsätta en stund till som om inget har hänt.

Det konstiga är att när jag kört diagnostester (HD Tune, Crystaldiskmark och Parted Magic) så visar alla att det inte skulle vara något fel på disken överhuvudtaget, och läs/skrivhastigheterna i Diskmark verkar ligga normalt om jag jämför med andra diskar i samma maskin, därav jag sliter mig i håret då det är när man använder disken "på riktigt" som jag upplever dessa problem, men kör man ett gäng tester på den så presterar den utan några konstigheter alls

Någon som har nån idé om vad det kan vara? Testat byta ut kablage, byta port på moderkort, provat helt annan sata-kontroller och testat lägga in ett script som ska omöjliggöra att den disken går i viloläge av sig själv, inget av detta har gett något resultat.

Screenshot Crystaldiskmark på WD Black-disken det gäller
https://i.imgur.com/7MKvMz4.png
Screenshot på en annan disk (WD Red 5400 RPM) som funkar perfekt utan dessa problem
https://i.imgur.com/ughxX84.png
Tack på förhand!

Klassikern (förr) var att man hade en disk med 4K sektorer fysiskt och 512B logiskt och felalignad partition. Typiskt 1:a partition börjar på sektor 63 och inte 2048. Ger precis se symtom som du beskriver. Kan ju vara värt att kolla upp.

Permalänk
Medlem
Skrivet av Tuborgarn:

...Har redan kollat efter skadade sektorer samt skrivit random data över hela disken för att testa, inga problem alls. ...

Kom att tänka på en sak. inte så att disken är kraftigt fragmenterad? Tar för givet att du formaterat om disken flera gånger av ditt inlägg, men ändå. Så vi råkar ut för riktig facepalm.

Visa signatur

Server: Fractal design Define 7 XL | AMD Ryzen 7 5800X 8/16 | ASUS ROG CROSSHAIR VIII DARK HERO | 64GB Corsair @ 3000MHz | ASUS Radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2TB Samsung 850 PRO SSD | 6x Seagate Ironwolf Pro 10TB
WS: Phantex Entoo Elite | AMD Ryzen Threadripper 1950X 16/32 | ASUS Zenith extreme | 128GB G.Skill @ 2400MHz | ASUS Radeon HD7970 | 3x 2TB Samsung 960PRO M.2 | 6x Seagate Ironwolf Pro 10 TB
NEC PA301W 30" @ 2560x1600 | Linux Mint 21.3 Cinnamon

Permalänk
Medlem

NTFS kan lätt bli mycket fragmenterad om det har använts som lagringsdisk för tex. torrent-nedladdningar - och det är så pass illa att varken defragmentering eller att ta bort filerna igen riktigt återställer det igen (beror på att mycket skrivs i $MFT - speciellt om disken har varit nära full under torrent-övningarna och datat och metadatat som lagras där är inte inte inpassat mot sektorgränser inom $MFT utan övergångarna mellan filerna/blocken är 'flytande' och därmed kostsamma att läsa och skriva senare. En sak till, MS egna defragprogram petar inte i $MFT - kan förvisso flytta på hela $MFT och göra den sammanhängande vid defrag men städar inte inom den, där det verkligen behövs i avseende prestanda...

Har man det läget så är det bästa för att få tillbaka farten helt enkelt att tömma disken på filer - ta bort partitionen, göra en ny partition och sedan skapa en ny NTFS-filsystem och sedan skriva tillbaka filerna igen - då blir dessa skrivet i linjärt kontinuerligt och $MFT fylls på med metadata något så när vettig ordning. Detta kan också påverka SSD som trots sin söksnabbhet faktiskt kan blir betänkligt långsamt - även SSD behöver göras defrag på - inte lika ofta som en snurrdisk men kanske en gång per år i alla fall.

Permalänk

Har äntligen haft tid att kolla upp lite mer grejer angående hårddisken nu, stör mig fortfarande lika mycket på det, tiden har helt enkelt inte räckt till bara tack för alla svar, uppskattas!

Skrivet av thu:

@Tuborgarn: som sagt, ge oss smartdatan så bör vi kunna ge bättre svar:)

Ser som sagt inga konstigheter. Värt att notera är möjligen att tid i drift står som N/A i Aida64, men HD Tune hittar den datan utan problem (körtid 385 dagar).

Skrivet av xxargs:

Vilken miljö kör du VM i när du har problemet - linux/windows/VMware ? - det framgår inte riktigt vid en snabbare läsning

varför frågan är om problemen är under just en enda OS/VM-miljö eller om samma sak sker under flera OS

Virtuella maskiner var bara ett exempel, detta gäller ju allt som skriver till/läser från disken som det verkar. Men för att svara på frågan så växlar jag mellan hyper-v och vmware workstation beroende på syftet med maskinen. Windowsmiljö.

Skrivet av OldComputer:

@Tuborgarn: Är Skrivcachen aktiverad i ditt OS? Prova både med och utan den aktiverad. Observera att det är den skrivcache som finns i ditt OS, inte den inbyggda cachen i disken.

Blir det samma om du kopierar en fil som är bra liten (max 100MB) samt även medel (som ryms i din RAM), samt en rejält stor (mer än 100GB)?

Provat stänga av indexeringen? Den ökänd i Windows för att sega ner datorn. Gör det på alla diskar, även på SSD / M.2.
Stäng även av allt kontraspionage som Windows använder sig av.

Om din systemdisk är en SSD/M.2, rensa ur cache från browsers, tempfiler och papperskorgen och framtvinga en trim på på den disken.

Kolla i enhetshanteraren om du får upp någon varningstriangel för disken.

Kollat att partitionen inte "ligger snett" gentemot diskens fysiska struktur? Detta ses lätt i fdisk i linux samt i gparted.

Skriv också vad maskinen innehåller.

Den är inte aktiverad. Har testat aktivera den som du skrev men det blir ingen skillnad. Indexeringen är avstängd och vad jag märkt så blir det ingen skillnad om man flyttar stora eller små filer, det verkar vara mer random. OS SSD är trimmad nyligen och har inga tempfiler som ligger och skräpar, kör den datorn som server så använder den inte alls till surf och annat, blir inte så mycket "skräp" då. Vad du menar med att partitionen ligger snett är jag inte riktigt med på dock? Formaterat den med gparted innan då jag testade disken med linux för att se om det var nån skillnad men såg inga konstigheter där, samma beteende verkar dock vara i linux men har inte testat det så djupgående. Disken innehåller typ ingenting just nu, tänkte ha den som lagring för vm's och isofiler men om den ska hålla på på detta viset så är det bara att glömma att köra virtuella maskiner från den.

Skrivet av SAFA:

Klassikern (förr) var att man hade en disk med 4K sektorer fysiskt och 512B logiskt och felalignad partition. Typiskt 1:a partition börjar på sektor 63 och inte 2048. Ger precis se symtom som du beskriver. Kan ju vara värt att kolla upp.

Inte riktigt med på vad du menar här, paste:ar sektor-info från msinfo32 nedan

Skrivet av OldComputer:

Kom att tänka på en sak. inte så att disken är kraftigt fragmenterad? Tar för givet att du formaterat om disken flera gånger av ditt inlägg, men ändå. Så vi råkar ut för riktig facepalm.

Tror vi börjar närma oss en lösning här kanske, min första tanke när jag läste ditt inlägg var "inte fan är den fragmenterad, har ju nyligen blåst disken", tog en koll ändå och körde en manuell analys i Windows eget defragmenteringsverktyg - döm av min förvåning när det står att den är 85% fragmenterad Dessutom står det att den defragmenterats automatiskt för mindre än en vecka sedan. Ska köra en manuell defrag så återkommer jag kring detta, men hur kan en nyformaterad disk bli fragmenterad när man knappt har nån data på disken? Detta har jag aldrig sett innan.

Skrivet av xxargs:

NTFS kan lätt bli mycket fragmenterad om det har använts som lagringsdisk för tex. torrent-nedladdningar - och det är så pass illa att varken defragmentering eller att ta bort filerna igen riktigt återställer det igen (beror på att mycket skrivs i $MFT - speciellt om disken har varit nära full under torrent-övningarna och datat och metadatat som lagras där är inte inte inpassat mot sektorgränser inom $MFT utan övergångarna mellan filerna/blocken är 'flytande' och därmed kostsamma att läsa och skriva senare. En sak till, MS egna defragprogram petar inte i $MFT - kan förvisso flytta på hela $MFT och göra den sammanhängande vid defrag men städar inte inom den, där det verkligen behövs i avseende prestanda...

Har man det läget så är det bästa för att få tillbaka farten helt enkelt att tömma disken på filer - ta bort partitionen, göra en ny partition och sedan skapa en ny NTFS-filsystem och sedan skriva tillbaka filerna igen - då blir dessa skrivet i linjärt kontinuerligt och $MFT fylls på med metadata något så när vettig ordning. Detta kan också påverka SSD som trots sin söksnabbhet faktiskt kan blir betänkligt långsamt - även SSD behöver göras defrag på - inte lika ofta som en snurrdisk men kanske en gång per år i alla fall.

Se svaret ovan. Förstår jag dig rätt nu alltså med att jag bör köra en clean i diskpart, initiera disken på nytt, skapa filsystem (formatera) och därefter köra ett defrag-verktyg? Nu börjar det komma lite hopp om att kanske få fart på härket iallafall ( ) men fortfarande jäkligt konstigt med tanke på att detta är en mkt oanvänd disk i jämförelse till andra diskar i samma server som hängt med flera år och som dagligen skriver och läser flera ton mer data än denna, de flesta är dessutom fyllda till bredden. Och dessa är inte i närheten lika fragmenterade som denna.

Stort tack för alla svar hittills!

EDIT: Något verkar helskumt med att disken fragmenteras så fort det hamnar lite filer på den som det verkar. Tänkte göra ett försök igen att formatera om disken för att kolla om den står som lika hårt fragmenterad när den är helt nyformaterad och ingen fil skrivits på den alls, flyttade över ett fåtal filer till en annan disk och körde en analys igen - 4% defragmenterad. Formaterade den och kollade ännu en gång - 0%, så långt är allt som det borde, men efter detta så ska ju inte filerna man flyttar till disken orsaka fragmentering då den är markerad som tom(?). Testar i skrivande stund att skriva över alla sektorer med nollor, och ska sedan göra om samma test. Om inte det funkar är mitt enda hopp jag kan komma på själv att testa med ett tredjeparts defragmenteringsverktyg men tycker som sagt det är riktigt märkligt att disken blir fragmenterad på detta sätt från att inte ha vart använd alls till att man skriver information på den en gång.

Permalänk
Medlem
Skrivet av Tuborgarn:

Har äntligen haft tid att kolla upp lite mer grejer angående hårddisken nu, stör mig fortfarande lika mycket på det, tiden har helt enkelt inte räckt till bara tack för alla svar, uppskattas!

https://i.imgur.com/eofNGeF.png
Ser som sagt inga konstigheter. Värt att notera är möjligen att tid i drift står som N/A i Aida64, men HD Tune hittar den datan utan problem (körtid 385 dagar).

Virtuella maskiner var bara ett exempel, detta gäller ju allt som skriver till/läser från disken som det verkar. Men för att svara på frågan så växlar jag mellan hyper-v och vmware workstation beroende på syftet med maskinen. Windowsmiljö.
Den är inte aktiverad. Har testat aktivera den som du skrev men det blir ingen skillnad. Indexeringen är avstängd och vad jag märkt så blir det ingen skillnad om man flyttar stora eller små filer, det verkar vara mer random. OS SSD är trimmad nyligen och har inga tempfiler som ligger och skräpar, kör den datorn som server så använder den inte alls till surf och annat, blir inte så mycket "skräp" då. Vad du menar med att partitionen ligger snett är jag inte riktigt med på dock? Formaterat den med gparted innan då jag testade disken med linux för att se om det var nån skillnad men såg inga konstigheter där, samma beteende verkar dock vara i linux men har inte testat det så djupgående. Disken innehåller typ ingenting just nu, tänkte ha den som lagring för vm's och isofiler men om den ska hålla på på detta viset så är det bara att glömma att köra virtuella maskiner från den.
Inte riktigt med på vad du menar här, paste:ar sektor-info från msinfo32 nedan
https://i.imgur.com/QjL9yNc.png

Menar samma sak som "hamnar snett" ovan. Börjar partitionen enligt bilden så är det 4096 st 4096 bytes block in på disken, så då är den inte "snett".

Citat:

Tror vi börjar närma oss en lösning här kanske, min första tanke när jag läste ditt inlägg var "inte fan är den fragmenterad, har ju nyligen blåst disken", tog en koll ändå och körde en manuell analys i Windows eget defragmenteringsverktyg - döm av min förvåning när det står att den är 85% fragmenterad Dessutom står det att den defragmenterats automatiskt för mindre än en vecka sedan. Ska köra en manuell defrag så återkommer jag kring detta, men hur kan en nyformaterad disk bli fragmenterad när man knappt har nån data på disken? Detta har jag aldrig sett innan.
Se svaret ovan. Förstår jag dig rätt nu alltså med att jag bör köra en clean i diskpart, initiera disken på nytt, skapa filsystem (formatera) och därefter köra ett defrag-verktyg? Nu börjar det komma lite hopp om att kanske få fart på härket iallafall ( ) men fortfarande jäkligt konstigt med tanke på att detta är en mkt oanvänd disk i jämförelse till andra diskar i samma server som hängt med flera år och som dagligen skriver och läser flera ton mer data än denna, de flesta är dessutom fyllda till bredden. Och dessa är inte i närheten lika fragmenterade som denna.

Stort tack för alla svar hittills!

EDIT: Något verkar helskumt med att disken fragmenteras så fort det hamnar lite filer på den som det verkar. Tänkte göra ett försök igen att formatera om disken för att kolla om den står som lika hårt fragmenterad när den är helt nyformaterad och ingen fil skrivits på den alls, flyttade över ett fåtal filer till en annan disk och körde en analys igen - 4% defragmenterad. Formaterade den och kollade ännu en gång - 0%, så långt är allt som det borde, men efter detta så ska ju inte filerna man flyttar till disken orsaka fragmentering då den är markerad som tom(?). Testar i skrivande stund att skriva över alla sektorer med nollor, och ska sedan göra om samma test. Om inte det funkar är mitt enda hopp jag kan komma på själv att testa med ett tredjeparts defragmenteringsverktyg men tycker som sagt det är riktigt märkligt att disken blir fragmenterad på detta sätt från att inte ha vart använd alls till att man skriver information på den en gång.

Skriver du över disken med nollor i linux, så kan du kolla skrivprestanda med iostat, typ

iostat -m 60
eller
iostat -m 60 | grep sdX # om du bara vill se från den disken.

Så ser du MNytes per sekund skrivprestanda varje minut. Ska ju ligga i runda slängar 100MB/sec beroende på disk o var på disken man skriver.

Permalänk
Medlem

100 MByte/s på en 3.5" snurrdisk??

Prata du om en gammal 2010 års generation WD-green 2TB?? (110 MByte/s, genomsnitt börja-slut 85.8 MByte/s, 20.5 ms genomsnittlig söktid)

En gammal WD-RED WD30EFRX (3TB) är dock inte så snabb den heller med topp på 140 MByte/s och genomsnitt 112.9 MB/s och söktid på av 16 ms. - jag har 2.5" diskar som är i ungefär samma nivå

en Toshiba N300 4TB (7200 RPM) låg på 210 MByte/s, genomsnitt 169.8 MByte/s mätt från början till slut och genomsnittlig söktid 11.76 ms - ljudnivå på exemplaret jag fick knappt noterbart mycket högre än WD-RED (något mer sus) trots den högre varvet. söknings-knäpparna är dock betydligt högre. Moderna diskar har helt klart bättre balansering än tidigare och förmodligen hänger ihop med att man packar dessa med tätare spår.

Runt och tom. över 200 MByte/s bör man nog ligga på en modern generations 6-8 TB disk för att sakta sjunka mot 100 MByte/s precis i slutet av körningen... med runt 160 MByte/s som genomsnittlig hastighet

moderna 7200 RPM stordiskar kan tom. uppnå uppemot 245 MB/s i början.

Permalänk
Skrivet av xxargs:

100 MByte/s på en 3.5" snurrdisk??

Prata du om en gammal 2010 års generation WD-green 2TB?? (110 MByte/s, genomsnitt börja-slut 85.8 MByte/s, 20.5 ms genomsnittlig söktid)

En gammal WD-RED WD30EFRX (3TB) är dock inte så snabb den heller med topp på 140 MByte/s och genomsnitt 112.9 MB/s och söktid på av 16 ms. - jag har 2.5" diskar som är i ungefär samma nivå

en Toshiba N300 4TB (7200 RPM) låg på 210 MByte/s, genomsnitt 169.8 MByte/s mätt från början till slut och genomsnittlig söktid 11.76 ms - ljudnivå på exemplaret jag fick knappt noterbart mycket högre än WD-RED (något mer sus) trots den högre varvet. söknings-knäpparna är dock betydligt högre. Moderna diskar har helt klart bättre balansering än tidigare och förmodligen hänger ihop med att man packar dessa med tätare spår.

Runt och tom. över 200 MByte/s bör man nog ligga på en modern generations 6-8 TB disk för att sakta sjunka mot 100 MByte/s precis i slutet av körningen... med runt 160 MByte/s som genomsnittlig hastighet

moderna 7200 RPM stordiskar kan tom. uppnå uppemot 245 MB/s i början.

Vart får du dessa siffror ifrån? Se skärmdumparna från CrystalDiskMark i TS

Permalänk
Medlem

Mer som kommentar från SAFA i sista raden i inlägget innan. 100MB/s är ifrån en tid runt 2010 och det har hänt en del sedan dess även på snurrdiskar

Brukar vara kutym och tom. bortlåst funktion på många forum man inte citerar på ett föregående inlägg precis innan - bara om det kommit en massa inlägg mellan och man inte längre ser flödet i diskussionen på ett bra sätt - hade det avsett som kommentar till inlägget i början med crystal disk info så hade det förstås funnits en citat som kopplar till just den inlägget

Permalänk
Medlem
Skrivet av xxargs:

100 MByte/s på en 3.5" snurrdisk??

Prata du om en gammal 2010 års generation WD-green 2TB?? (110 MByte/s, genomsnitt börja-slut 85.8 MByte/s, 20.5 ms genomsnittlig söktid)

En gammal WD-RED WD30EFRX (3TB) är dock inte så snabb den heller med topp på 140 MByte/s och genomsnitt 112.9 MB/s och söktid på av 16 ms. - jag har 2.5" diskar som är i ungefär samma nivå

en Toshiba N300 4TB (7200 RPM) låg på 210 MByte/s, genomsnitt 169.8 MByte/s mätt från början till slut och genomsnittlig söktid 11.76 ms - ljudnivå på exemplaret jag fick knappt noterbart mycket högre än WD-RED (något mer sus) trots den högre varvet. söknings-knäpparna är dock betydligt högre. Moderna diskar har helt klart bättre balansering än tidigare och förmodligen hänger ihop med att man packar dessa med tätare spår.

Runt och tom. över 200 MByte/s bör man nog ligga på en modern generations 6-8 TB disk för att sakta sjunka mot 100 MByte/s precis i slutet av körningen... med runt 160 MByte/s som genomsnittlig hastighet

moderna 7200 RPM stordiskar kan tom. uppnå uppemot 245 MB/s i början.

Nå nu toppar ju TS:ok disk på 128 MB/s och det brukar ju droppa till ca hälften på slutet. Den disken hade ju inga problem. Så klarar hans problemdisk att skriva med 100MB/s över HELA disken så borde han inte ha problem med den och man kan ju utesluta att tex läs/skriv prestanda degraderar efter ett tag. Dvs problemet torde då inte vara hårdvaran.

Har för övrigt räddat data åt en bekant där disken klarade att läsa i full fart ca 30 sekunder innan den den fick permanent läsfel. Kopierade man filerna lite långsamt så kunde den jobba i kanske 5-10 minuter innan man fick låta den vila. Eftersom Windows alltid ville köra checkdisk på den vid start så kunde han aldrig se några filer innan disken gav upp för denna gång.

Permalänk
Medlem

Hmm, jag gjorde samma miss som Tuborgarn som bara läste de två första bilderna i starten av tråden och avsåg en WD-Black, inte bild 3 och 4 för just WD-red som tråden egentligen handlar om...

Och 128 MB/s är inte speciellt snabbt idag... för en 6TB-disk av något så när modern slag borde man ligga och sniffa på 180-200 MB/s - Seagates Archivedisk på 8 TB från troligen ungefär samma årtal låg och toppade på 205 MB/s när jag mätte, förvisso hade den 5900 RPM istället för 5400 RPM som WD-Red, men det förklarar inte hela skillnaden.

Disk som toppar på 128 MB/s är dödligt långsamt även om man flyttar stora sammanhängande filer i jämförelse med diskar som toppar kring 200 MB/s...

diskräddning:

Låter liknande beteende som en WD-Book som man i slutet fick klä om med påsar med isbitar för att få ut det sista - eller den 2.5" WD-passport som jag har som också blir helt fel så fort det är drygt 27 grader C...

Nej det är inget fel att prova med lägre hastighet om det krånglar, på någon extern USB-disk som också hade hängningar vid massiva läsningar så bytte jag sladd till en USB2 och i och med lägre hastighet då gick bättre - där var det USB/SATA-chipet i kabinettet som dummade sig då disken invändigt inte hade några issuer när den sedan användes löst.

på den tiden var det viktig att läsa ut all data innan man scrappade kabinettet då de transformerade 512-bytes sektorer till 4K-sektorer i USB/SATA-chipet för att komma runt MBR:s 2TB begränsning och försökte man läsa disken i en diskdocka utan översättning så blev det inte bra när LBA-nummren på sektorerna adresserades på 512-bytes nivå medans MBR och Filsystemet förutsatte LBA-adressering på 4K-sektorer