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

Det är väldigt få som pillar i HPA och/eller DCO så det är inte det första att misstänka vid diskstrul, ja, om det inte kommer från olika typer av servrar i olika lagringssystem där man med märkesinlåsning försöker göra diskarna odugliga i något annat än deras egna maskiner - dock i de fallen är diskarna ofta av SAS-modell.

det andra är att det faktiskt blivit korruption av config-data i disken SA-area eller att någon program körts och det inte blev rätt (läs hdparm - den har en del rätt vassa funktioner som man lätt kan bli blodig av eller göra om diskar till dörrstopp/brevpress eller isärplockade till blanka skinande drink-underlägg och väldigt starka kylskåpsmagneter)

Har inte hunnit läsa igenom allt så noga men det verkar ju som att du löst problemet.

Gött.

Är dom SAS-diskar

Har man någon av P400, P410, P420 RAID-kontroller (de med ECC-RAM write-cache och batteribackup) i sin HPE-server och diskarna är satta i RAID så har de alla en LSI-header i början som konfigurerar i hur RAID:en ser ut

Hamnar dessa diskar i en annan dator med HBA och LSI-baserad chipset så kan det ge krångel - så sådana diskar bör man rensa början på med en HBA satt i IT-mode (eller vanlig diskdocka om det är SATA-diskar) så att den inte försöker tolka datat på de första cylindrarna eller början av diskvolymen.

Nu läste jag lite vidare på HPA och/eller DCO och det verkar inte vara helt ovanligt använd på märkesdatorer som Dell och Lenovo för att tex. gömma recovery-partitioner så att dessa inte försvinner när någon gör full disköverskrivning och BIOS vid kall-boot kan hitta dessa (men inte vid varm-reboot) - vilket också kan användas för virus och malware som försöker gömma sig för att vara peresistent i kombination med vissa BIOS som hittar dessa HPA-areor vid boot som möjliggör att den aktiveras igen och överlever disk-wipe typisk aktion efter virusattack, och till det olika root-kit som försöker gömma sig på samma sätt.

Normalt plockar man bara någon enstaka GB i slutet av disken för HPA och varför TS diskar bara har enstaka GB kvar för att HPA/DCO är omsatt tyder på att det kan ha en intressant historia (tex. använd i servrar för videoinspelning med någon suspekt propertiär mjukvara) eller resultatet av en rootkit/malware.

HPA/DCO verkar inte finnas i SAS-världen utan är SATA-specifikt. SAS har andra mekanismen och de kan stöka till också när det gäller totalvolym på lagringen...

Har dock svårt att tänka mig att kontroller som P410 som är gjorda för dualport-SAS enterprise-diskar[1] skulle mickla avsiktligt med HPA/DCO på SATA diskar då dessa räknas som low-end diskar och tex. HGST Ultrastar med dual port SAS-gränssnitt och motsvarande från Toshiba och Seagate räknas som Near Line Enterprise-diskar.

"Riktiga" Enterprise-diskar har rejält utökad ECC - och dess extra paritet tar ordentligt med plats vilket förklarar de 'udda' storlekarna som 146, 300, 600, 900 GB storlek. tex. klarar Cheetah 320 bitar oläsbar data i rad på disken och ändå rätta det 'on the fly' utan omläsning vilket är långt mer än vad en standard snurrdisk klarar. - och på SCSI-sätt kommer denna skadade sektor automatiskt skrivas om och ev. reallokeras om det inte går att skriva om, så fort disken är ledig så fort läsproblemet upptäckts.

[1]
Läs i praktiken OEM Seagate Cheetah - 15 krpm-diskarna har 2 ms genomsnittlig söktid, en 3.5" disk av bättre sort är knappt under 12 ms i genomsnittlig söktid, en WD-green 2TB är runt 21 ms...

Det intressanta att hämta data över USB mot extern SSD/NVMe verka ha en söktid på runt 1 ms - antagligen pga. USB-stackens rejält tilltagna overhead att starta en transaktion - när den väl rullar så rasslar det dock på fort... (detta var ett aber förr när man skulle ha realtidsinhämtning av data från mätinstrument och ofta körde man hellre 1394-gränsnitt (firewire) med planerbar bandbredd och responstid)