Du har väl kopierat ut filerna hoppas jag ??
C7 (CRC32 error i SATA) har varit dåligt en gång i tiden och kunde ha förklarats med dålig SATA-kabel - men är på 127 nu vilket tyder att problemet är löst.
Vad värre är att BC (command time out) är på värde '1' både innan och nu och troligen förklaringen till trögheten då att stallar och vänta på reset hela tiden tar tid och detta ger ingen hög dataflöde.
Jag skulle prova under linux (live-DVD/sticka) och flytta lite filer och se vad 'dmesg' (som root i terminalfönster) säger - också ett bra sätt att kolla att det inte är OS-beroende.
Nästa steg är att köra det i en USB-diskdocka av bättre kvalisort (skulle prova med https://www.webhallen.com/se/product/306479-Nedis-Dockningsst... framför Deltaco-dockan då förstnämnda har med stor sannolikhet Asmedia-chip ASM1156 och inte som i Deltaco-docka med Jmicrons JM56x-chip som är mer än lovligt buggig och hänger sig och som bara kan fås igång med USB-busreset, och i linux väntar det länge innan busreset vilket gör att dataflödet blir inte bra då det haltar ofta och speciellt om man har snabbare media inkopplad och speciellt på A-porten).
Har förvisso bara kör diskdocka med ASMT105-chip men dessa har varit väldigt driftsäkra och stabila även vid väldigt hög last (+500 MB/s kontinuerligt från SSD) utan krusiduller.
- detta prov också för att man skall få helt annan strömförsörjning som inte är datorns ifall det är trubbel på 5 och 12 Volt sidan i matningen av disken som stör
Och som sista steg innan skrotbeslutet så skulle jag skriva disken från början till slut med 'dd'
Först i linux livedisk (som knoppix, systemrescuesd eller motsvarande med fokus på dataräddning) med 'lsblk' ta reda på vilken enhet disken sitter på och vi säger att disken identifieras på /dev/sdb för exemplet.
(vad enheten döps vid anslutning och vilken ordning om det finns flera lika enheter av tex. diskar bestäms inte av OS alls utan PCIe-subsystemet på själva moderkortet och delar av BIOS för att det skall vara Plug and play - och då är allt dynamiskt och kan byta plats var gång, var start - därför måste man _alltid_ kolla med lsblk innan man använder 'dd' mot diskar och partitioner, annars kan det gå illa)
Sedan
"dd if=/dev/zero of=/dev/sdb bs=1024k status=progress"
och får den köra från sektor 0 till sektor slut vilket vilket kommer ta minst 12-15 timmars session att genomföra.
(koppla ur fysisk alla andra diskar som har viktig data om du inte är säker på hanterandet och addresserar rätt diskar - för det här rensar data och om det går till fel disk blir det inte bra alls - det finns inget här som lägger fingrarna mellan och 'dd' kallas också för 'data-destroyer' och det finns god grund för det nicknamnet )
Sedan efter köra sedvanliga tester efter detta och se om det blivit sprutt på disken.
---
Varför denna övning - jo om spåren är vingliga (vi pratar vingel på mindre än 50 nm) för att det skrivits för att disken utsatts för vibrationer så kan det har problem med att läsa senare och spenderar mycket tid på det med både omläsningar och olika ECC-operationer och det stallar/ger time out. Detta behöver inte ge några noteringar i SMART, man är faktiskt väldigt dåligt på det hos de flesta disktillverkarna...
När man skriver data från sektor 0 till sektor slut så skiter disken i vad som fanns innan (utöver synk-märkerna) på skivan när den skriver (och verifierar direkt efter) och helt plötsligt är det raka spår på skivan om det hela görs i lugn och vibrationsfri miljö och efter denna process har inte disken några problem längre och är ofta som nyfödd.
Det är mer än en disk jag fått ur hopplös situation där även tillverkarnas egna diagnostikprogram dömt ut disken till att efter ovanstående körning så hittas inga fel alls.
Det är värt ett prov i alla fall - blir det inte bättre så blir det till att döma ut disken till elektronikåtervinningen.
