HDD wordt niet herkend: incorrect number of bytes per sector

[Grrrrrene]

Vorige week is mijn laptop definitief overleden: de GPU is waarschijnlijk doorgefikt. Ik kreeg in eerste instantie rare blokken en strepen in beeld en nu blijft het beeld zwart bij het booten (op een externe monitor zie ik de blokken/strepen nog wel). Doordat het beeld zwart cq. onleesbaar bleef, heb ik de laptop een paar keer geforceerd moeten afsluiten, waardoor (denk ik) de 1TB partitie op de hdd beschadigd is geraakt.

Als ik hem aansluit via een USB-behuizing op mijn nieuwe laptop, krijg ik meteen de vraag of ik de schijf wil formatteren. Dat doe ik uiteraard niet. Onder disk management wordt de schijf netjes weergegeven als een 1TB schijf met een "RAW" partitie erop. Ik kan geen andere actie kiezen dan formatteren en dat wil ik (uiteraard) niet.

Vervolgens plug ik hem in mijn zelfbouw Linux-NAS en die geeft de schijf ook niet weer (wil niet automatisch mounten). Onder Disk Utility ziet hij de schijf wel, maar er zou een 8TB partitie op aanwezig zijn, gevolgd door een -7TB (ja, negatief) 2e partitie. Screenshot van Testdisk:



Deze factor 8 verschil tussen de fysieke grootte van de schijf en de partitie lijkt te komen doordat de sectorgrootte incorrect is. De partitie rapporteert blijkbaar 4096 bytes/sector, terwijl dat in werkelijkheid 512 bytes zou moeten zijn, volgens Testdisk. Screenshot van testdisk (bezig met grondig scannen van de partitie, duurt lang!) hieronder:



Uiteraard heb ik gezocht hoe ik dit opgelost kan krijgen en dat zou met Testdisk moeten kunnen. Als ik de partitie laat scannen kan ik de files zichtbaar krijgen in testdisk. Ik heb de stap voor stap handleiding hier gevolgd tot de stap "Save the partition table or search for more partitions?", ongeveer halverwege de pagina. Daar loopt het vast op het probleem dat ik de juiste partitie (de backup gok ik?) niet kan terugzetten (door "Write" te selecteren en op enter te drukken), omdat hij blijkbaar niet kan schrijven naar de partitie (althans, dat is de foutmelding). En daar houdt mijn expertise eigenlijk ook een beetje op.

Dat ik de files zichtbaar kan krijgen in testdisk stemt me positief. De files zijn er nog en zouden niet beschadigd mogen zijn. Maar dat de partitie niet gerepareerd kan worden door testdisk is problematisch. Heeft iemand enig idee hoe ik de partitie kan herstellen? Ik kan niet zo heel veel informatie vinden over partities met de verkeerde sectorgrootte, maar als leek lijkt het me niet onmogelijk om die sectorgrootte weer goed te krijgen, toch? Waarom kan testdisk niet naar de schijf schrijven?

[_JGC_]

Denk dat je op de goede weg zit. Voor je met testdisk aan de slag gaat raad ik je aan om met dd een image van de hele disk te maken en hiermee te gaan testen ipv op je echte schijf. Kans dat je je data dan weer gaat zien is een stuk groter, als je het verknalt met je harddisk is het nml na de bewuste actie meteen over en uit.

[Uncle Mel]

Verwijderd

[ Voor 95% gewijzigd door Uncle Mel op 30-01-2014 21:20 ]

[Mijzelf]

Een mogelijke workaround: Veel (alle?) usb-to-sata convertors geven een logical sector size van 4096 bytes bij een schijf >2TiB, ongeacht wat de schijf ervan vindt.
Dus als je een lowlevel copie maakt naar een 3TB disk, en deze via USB aansluit op een Linux systeem, kun je de partitie mogelijk gewoon mounten.

[_JGC_]

Deze disk is een AF disk, wat inhoudt dat de fysieke sectoren 4K zijn, maar de logische sectoren 512bytes zijn. Op een of andere manier is er iets in de partitietabel vern*kt waardoor de disk ineens denkt dat de logische sectoren ook 4K zijn, wat inhoudt dat de disk ineens 8x zo groot is.

Hoe en wat kan je als volgt zien:
dmesg | grep logical
geeft als het goed is zoiets als dit:
[ 1.719650] sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)

parted /dev/sda
p
vervolgens zou je iets als volgt moeten zien:
Sector size (logical/physical): 512B/512B

In het geval van jouw disk zou dat 512B/4K moeten zijn.

Kan overigens ook zijn dat je USB converter gewoon buggy is en zoals bovenstaand niet alleen voor >3TB disks geldt, maar gewoon voor alle disks met 512e formaat, in dat geval is er helemaal niks met je disk aan de hand, maar is je USB convertor gewoon brak.

[Grrrrrene]

_JGC_ schreef op maandag 14 oktober 2013 @ 12:29:
Denk dat je op de goede weg zit. Voor je met testdisk aan de slag gaat raad ik je aan om met dd een image van de hele disk te maken en hiermee te gaan testen ipv op je echte schijf. Kans dat je je data dan weer gaat zien is een stuk groter, als je het verknalt met je harddisk is het nml na de bewuste actie meteen over en uit.

Dan zal ik een nieuwe 1TB-schijf moeten kopen. Ik heb er een in mijn nieuwe laptop, maar dat is de systeemschijf (met caching SSD) en verder heb ik niet dit soort schijven rondslingeren. Wel een goed punt trouwens,

Uncle Mel schreef op maandag 14 oktober 2013 @ 12:55:
Het is wel zo goed als onmopgelijk om de sector size aan te passen omdat NTFS met blocks, clusters en sectoren door elkaar werkt. Zelfs als je deze allemaal handmatig aanpast (ja dat heb ik geprobeerd) vind windows het niet tof. chkdsk zal dan rapporteren dat het prima is, maar Windows zal niet fatsoenlijk de schijf mounten.

Zo goed als onmogelijk klinkt niet erg hoopvol

Heb je al eens met een directe sata verbinding geprobeerd?

Nog niet, ga ik doen als de "deep scan" klaar is (32% nu). Vanavond ergens dus...

Mijzelf schreef op maandag 14 oktober 2013 @ 13:07:
Een mogelijke workaround: Veel (alle?) usb-to-sata convertors geven een logical sector size van 4096 bytes bij een schijf >2TiB, ongeacht wat de schijf ervan vindt.
Dus als je een lowlevel copie maakt naar een 3TB disk, en deze via USB aansluit op een Linux systeem, kun je de partitie mogelijk gewoon mounten.

Als de fout daar zou zitten, zou het ook opgelost zijn als ik hem direct via SATA aansluit, of begrijp ik het dan verkeerd? Ik hoop heel erg dat het inderdaad aan een brakke converter ligt. Dat gaan we straks zien. Wat dat betreft allemaal heel erg bedankt, ik laat het hier weten als het inderdaad aan de converter lag. Zo leer je dagelijks bij

[Anoniem: 15758]

Kun je ook de SMART gegevens posten, voor de zekerheid?

smartctl -A /dev/sdf

Verder kun je ook eens een ander OS pakken om te kijken hoe die je disk detecteert, zoals BSD. ZFSguru livecd zou het hem kunnen doen. Je schijf hoort namelijk als 512B per sector herkend te worden.

Je kunt gewoon al je data recoveren hoor, als het niet op deze manier is dan kunnen we de partitie elders naartoe schrijven met 'dd'. Dus ik zou je data zeker niet als verloren beschouwen.

[Grrrrrene]

Ik heb hem net aan een SATA-kabel aan mijn WIndows 8-PC gehangen, maar ook daar kreeg ik de melding dat hij geformatteerd moest worden. Het lijkt me dus niet dat de converter van USB naar SATA hier het probleem is?

Vervolgens hang ik hem terug aan de NAS, loop naar beneden, zie via VNC dat hij helemaal niet gevonden wordt in Disk Utility. Ik wil net de smartctl -A /dev/sdf truc proberen, krijg ik de melding dat sdf niet bestaat. WTF? Oh, wacht, het is nu sdg om onduidelijke redenen.

Dus ik tik dat in voor sdg, zie ik ineens dat er onder "my places" een "1TB disk" is gemount. Jawel, de falende hdd. Ik ben nu dus bezig alles via het netwerk (tsja, 't is even niet anders, maar het is 1Gbit/s) naar mijn nieuwe laptop te kopiëren. Fingers crossed dat er niks corrupt is. Als alles in orde blijkt te zijn, durf ik pas verder te gaan met de falende disk. Ik weet nml niet of dit aan mijn geforceerd uitschakelen kan liggen of dat de disk fysiek niet in orde is. Ik wil dat laatste natuurlijk uitsluiten, want dan moet de disk retour.

De smart-gegevens trouwens:

code:

smartctl -A /dev/sdg
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   183   178   021    Pre-fail  Always       -       1833
  4 Start_Stop_Count        0x0032   094   094   000    Old_age   Always       -       6348
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       5208
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       317
191 G-Sense_Error_Rate      0x0032   098   098   000    Old_age   Always       -       2
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       253
193 Load_Cycle_Count        0x0032   196   196   000    Old_age   Always       -       12632
194 Temperature_Celsius     0x0022   121   100   000    Old_age   Always       -       26
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

Zegt me eigenlijk niet zoveel Maar nogal wat values zijn > worst en zaken als "Pre-fail" en "Old_age" (ding is ~1 jaar oud ofzo?) klinken wel raar.

[Anoniem: 15758]

SMART wordt heel vaak verkeerd geïnterpreteerd.

De genormaliseerde waarden Current/Worst/Threshold (in jouw output Value/Worstt/Thresh) gaan van 0 tot 255 (8-bit) en daarbij geldt: hoe hoger des te beter. De Current is de huidige waarde, Worst is de slechtst gemeten waarde in het verleden en Threshold is het punt waarop er officiëel een failure wordt gerekend. Pas als de Current value beneden de Threshold zakt, is die attribuut officiëel failed. Denk bijvoorbeeld aan de temperatuur. Jouw disk is ingesteld dat er bijna nooit een officiële SMART failure wordt opgegeven, dat vinden fabrikanten tegenwoordig beter om geen onnodige RMA te krijgen. Zo geeft jouw schijf pas een failure bij temperatuur boven de 150 graden celsius.

Dat pre-fail en old_age wordt ook geïnterpreteerd als iets engs. Maar een SMART attribuut kan uit twee typen bestaan: een attribuut wat voortijdig falen zou moeten aangeven, zoals heel veel bad sectors of een veel te lange spinup tijd. Andere attributen geven alleen ouderdom weer. Dus dat je schijf misschien al 10 jaar draait dan wordt een waarschuwing voor de ouderdom gegeven, maar dat heeft verder niet direct iets te maken met een acuut probleem wat de betrouwbare werking kan belemmeren.

Kortom, je SMART is prima. Het interpreteren ervan lukt meestal niet zonder dat iemand je uitlegt hoe SMART werkt. WikiPedia heeft ook een heel autistisch artikel over SMART waarbij ik het sterke vermoeden krijg dat de auteurs zelf SMART niet voldoende begrijpen, door de wijze waarop de attributen zijn omschreven.

Verder kan ik niet zo één twee drie vinden wat het typenummer is van jouw schijf? Zodra je alles hebt gebackupped kunnen we eventueel verder kijken, een ruwe dd zero write doen, enzovoorts.

[Grrrrrene]

Zo, alles is gebackupt op m'n NAS en komt nu naar m'm nieuwe laptop toe via het netwerk. *haalt opgelucht adem*

Dat het spontaan wel werkt geeft me weinig vertrouwen in de schijf. Heb ik daar gelijk in of kan er iets anders zijn wat dit onvoorspelbare gedrag kan verklaren?

_JGC_ schreef op maandag 14 oktober 2013 @ 13:34:
Deze disk is een AF disk, wat inhoudt dat de fysieke sectoren 4K zijn, maar de logische sectoren 512bytes zijn. Op een of andere manier is er iets in de partitietabel vern*kt waardoor de disk ineens denkt dat de logische sectoren ook 4K zijn, wat inhoudt dat de disk ineens 8x zo groot is.

Hoe en wat kan je als volgt zien:
dmesg | grep logical
geeft als het goed is zoiets als dit:
[ 1.719650] sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)

De output (3 regels?):

code:

[3738463.036081] sd 7:0:0:0: [sdg] 244190646 4096-byte logical blocks: (1.00 TB/931 GiB)
[3738463.054050] sd 7:0:0:0: [sdg] 244190646 4096-byte logical blocks: (1.00 TB/931 GiB)
[3738463.128054] sd 7:0:0:0: [sdg] 244190646 4096-byte logical blocks: (1.00 TB/931 GiB)

parted /dev/sda
p
vervolgens zou je iets als volgt moeten zien:
Sector size (logical/physical): 512B/512B

In het geval van jouw disk zou dat 512B/4K moeten zijn.

Hmm, het is 4096B/4096B Misschien ook wel logisch aangezien hij nu wel benaderbaar is...

code:

Model: WDC WD10 JPVT-22A1YT0 (scsi)
Disk /dev/sdg: 1000GB
Sector size (logical/physical): 4096B/4096B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1000GB  1000GB  primary               boot

Daarmee is ook meteen CiPHER's laatste vraag beantwoord: wat voor model is het. Een WD Scorpio Blue van 1TB in 2,5" formaat. Een WDC WD10 JPVT-22A1YT0 blijkbaar.