Det här med att återställa HDD till fabrikskapacitet... ?

Nja, Gparted går att köra utan nått vanligt operativsystem i botten så det kan komma åt lagringsenheterna utan de spärrar som ett vanligt os kan innebära.

Varför försöker du inte skriva över hela disken med zero på en gång istället?

Word.

Inte mycket jag gått bet på med så enkla grejor som Windows diskpart och FreeBSD dd, gpart, smartctrl, cam control etc.

Behövs oftast inte mer än så!

Edit: att säga att man provat allt innan man gjort minst en full DD write och read på en disk är lite som att knuffa in bilen på verkstad för att den inte startar utan att åtminstone slängt i några liter bränsle och laddat batteriet.

Dagar tar det inte - en gammal WD-Green 2TB kanske läser med genomsnitt 110 MB/s ( startar vid ca 140 MB/s vid perferiläsning och slutar vid ca 70 MB/s nära centrum)[1], och 2 TB tar då ca 18200 sekunder eller lite över 5 timmar att skriva igenom - skall man läsa disken igen så är det drygt 5 timmar ytterligare då det i flesta fallen är ungefär samma hastighet vid läsning som skrivning.

tar det mycket lägre tid vid skrivning och senare läsning och man ser skriv/lästakten mycket lägre än förväntat så är disken förmodligen problematisk

man kan göra speed-test med disks (i ubuntu-menyerna, gnome-disks om man startar på kommandorad) och är det stora hack upp och ned i fart vid 100MB/1000 MB-sampelblock) och inte en jämn sakta avtagande i fart när den kommer allt närmare centrum läs/skrivhastighet så har disken ofta problem.

- detta under förutsättning kör direkt med SATA till moderkortet, med en USB3 USB/SATA-adapter/diskdocka - envisas du med 2.0 USB adapter så är det 3 ggr mer tid samt att dessa i de flesta fallen inte klarar diskar över 2TB (pga. USB2-adaptrar ofta stöder bara 32-bits LBA och inte 48-bits LBA)

[1] En 2 år gammal 10 TB-disk disk ligger idag runt 220 MB/s och toppar kring 270 MB/s, dagens typ 14 - 22 TB diskar ligger över 300 MB/s.

Jag känner mig manad att tillägga att ovan endast är maxhastigheter. Behandlas många små filer är det fullt normalt att hastigheten störtdyker.

Vid en DD bör du dock få ut nära maxhastighet om disken är frisk, iom att det beter sig som en enda lång skrivning över hela disken.

som redan skrivet att använda 'dd' på raw-device som /dev/sdc så skriver den från LBA 0 och räknar upp sekventiellt LBA-nummermsässigt tills det tar stopp där disken tar slut.

Det ger inga stora läsarmröreler eller någon metadata som behöver sökas/uppdateras utan det skriver linjärt sekventiellt hela tiden med maximal fart.

Enstaka stora armrörelse kan förekomma under förloppet men är mer beroende av diskens firmware och att det är någon 'house-keeping' som behöver göras.

Däremot om man hör att disken gör en massa armrörelse och skriv och läsfarten droppar kraftigt så tyder det på omläsningar och omskrivningar ett antal gången och eventuell reallokering av sektorer som inte kan skrivas och då är inte disken att anses som riktigt frisk längre - särskilt om man också ser att SMART-värden (värde 5 och 196(dec) avseende reallokerade sektorer ökar medans om man hade värden högre än 0 på 197 och 198 (dec) så bör dessa vara nollställda efter en full skrivning med '0'

Jepp.

Har gjort precis så för att felsöka en gammal WD blue 500G som jag fick av en bekant, men som betedde sig väldigt..... mysko.

Kom fram till att någon punkterat packningen mot locket i sidan och att det kom in skräp i disken och fick den att blir konstigare och konstigare, inte helt uppenbart till en början men att göra DD write / reads och kolla smartdata fick mig att misstänka fysiskt fel.

Hur ser det up om du kollar upp om det ställts in någon HPA?
https://en.wikipedia.org/wiki/Host_protected_area

sudo dd if=/dev/zero of=/dev/sdi bs=1048576 count=1024

Man kan använda enhetssuffix för bs, så det kommandot är samma sak som:

sudo if=/dev/zero of=/dev/sdi bs=1M count=1024

D.v.s. kopiera 1024 st. 1MB-block från /dev/zero till den angivna disken. Så du kan behålla bs som det är och bara ändra count till diskens storlek i MiB.

 sgdisk --zap-all /dev/sdd

sgdisk är främst ett verktyg för att manipulera GPT-partitionstabeller, så tveksamt att det är till någon större hjälp här. --zap-all skriver bara över MBR/GTP-datan på disken, vilket du väl lär ha gjort flera gånger om redan. Men det skadar väl inte att försöka antar jag.

sudo dd if=/dev/zero of=/dev/sdd bs=1048576 count=1024

dd if=/dev/zero of=/dev/sdd

Du behöver varken ange bs eller count, datorn skriver tills disken tar slut om du inte anger count. Läs manualen till dd.

Jag förstår inte riktigt varför du länkar sidor som talar om hur DD fungerar till mig, jag vet hur det fungerar.

Jag ville bara påpeka att det inte behövs anges varken bs eller count för att det skall fungera, BS kan man labba med för maximal prestanda beroende på operation, men count kan normalt sett utlämnas. Jag brukar ange status=progress

Fast hur ska dd kunna veta hur mycket som ska skrivas när storleken på diskarna är fel?

Kör du en DD och låter den skriva tills disken tar stopp så är det ju bevisat att det inte är filsystem eller data på diskytan som är bekymret utan någon konfiguration i disken i sig själv.

Tycker du fick några bra tips i tråden att följa.

Vad säger t ex en full smartavläsning gällande fabrikskapacitet och tillgänglig kapacitet?

Det är irrelevant, låter du DD skriva tills det tar stopp så kommer det ta stopp på precis samma ställe om du försöker tvinga DD att skriva en större datamängd.

Intressant, måste fundera lite...