[zip/linux] Hoe defecte sectoren deels in lezen?

[TD-er]

Ik kreeg laatst een zip 750 USB in handen met een defecte zip-disk.
Op die disk staat uiteraard vrij veel belangrijke data, waar iemand heel erg blij mee is als er uberhaupt iets vanaf gehaald kan worden.

Onder windows hangt het OS, wanneer die disk erin geplaatst wordt. Blijkbaar wil windows 'm meteen mounten en daarvoor moet 'ie een aatal sectoren in lezen, die defect zijn.

Dan maar onder linux gebeuren. Op een redelijk schone redhat 8.0 install.
Dat leek vlekkeloos te gaan. Linux ziet de zip-drive meteen en maakt er een SCSI-device van. (sda)
Met fdisk kan ik zien dat het gaat om /dev/sda4 en zie het aantal sect/heads/cyl. en de blok-grootte (512 bytes)
Totaal 1'470'500 LBA-sectoren.

Toch even geprobeerd om een cat /dev/sda > image-file te doen, maar dan loopt 'ie vast op (LBA)sector 32.
Dan maar een iets andere aanpak met dd.
dd if=/dev/sda of=<beginsector>-<eindsector> bs=512 count=<verschil> skip=<beginsector>

Op die manier heb ik een heleboel blokken aan leesbare data kunnen vinden, maar juist voor de 200e sector zijn er erg veel sectoren defect. (daar staat een groot deel van de FAT, zo niet alles)

Ik heb alle losse stukken aan elkaar geplakt en de missende stukken opgevuld met 0-en. Zodoende kreeg ik een image file die linux wel wilde mounten. Helaas staan er alleen maar dir's op met als naam "????????.???", oftewel iets zegt me dat het niet goed genoeg is.

Is er een manier om zeg maar de SCSI-kernel-module te zeggen dat 'ie niet moet vallen over CRC-errors en gewoon de data zeg maar RAW in moet lezen?
Of gebeurd dat checken op een lage niveau, in de drive zelf?
Het leek erop dat er vanuit de kernel telkens een SCSI-reset gedaan werd en de betreffende sector steeds 5x opnieuw gelezen werd.
Tijdens dat skippen is de machine namelijk niet echt geweldig benaderbaar.
Ik hoop namelijk dat van die extra informatie er net genoeg bitjes benaderbaar zijn om het filesystem te kunnen reproduceren.
Op de rest van de schijf zijn er namelijk lang niet zo veel bad sectors, (sect 500 - 412992 is in elk geval goed leesbaar) oftewel hooguit wat files die niet helemaal meer kloppen. Het gaat hier niet om een grote zipfile van 700 MB ofzo, dus de kans dat er wat files te redden zijn is aanwezig.

Nog een ander punt. Het lijkt erop dat Linux de drive in grotere blokken aanspreekt dan 512 bytes, want als er een bad sector is, kan er vaak 8 - 16 kB eromheen niets gelezen worden. Als je dus RAW in kunt lezen zou je die data dus ook te pakken kunnen krijgen, waar waarschijnlijk niets mee mis is.

Iemand een suggestie?

zeer waarschijnlijk zullen dos-rescue-tools niet werken omdat het een USB-drive is.

[A_L]

Volgens mij was er voor dd ook een "no-error" optie. ( conv=noerror als ik het goed heb.)

/edit: Oh, wacht. Het er schijnt een speciaal dd-rescue te bestaan die bij leesfouten gewoon door gaat.
Een ander programmaatje dat ik op freshmeat tegenkwam, "myrescue", schijnt ongeveer hetzelfde te doen.

[ Voor 63% gewijzigd door A_L op 15-03-2003 15:01 . Reden: meer info ]

[Buffy]

Een normal FAT filesysteem heeft twee File Allocation Table's. De normale en een backup. Helaas wordt de backup FAT naast de echte opgeslagen dus of die nog te gebruiken is hangt af van hoe groot de FAT's zijn.
Voor een FAT16 filesysteem geldt dat er in een sector van 512 bytes 256 cluster (a 2048 bytes) pointers kunnen worden opgeslagen. Als dus alleen de eerste 200 sectors beschadigd zijn bevat deze hoogstens 200 * 256 cluster pointers oftewel 100 MB aan clusters.

M.a.w. als de zip driver groter dan 100MB is dan is zeer waarschijnlijk de backup FAT nog intact en kan die nog gebruikt worden om de data te restoren.

Probeer eens de image op een evengrote FAT partitie te zetten en scandisk er naar te laten kijken. Eventueel de boot sectors van een andere (even grote) zip disk aan de image toevoegen.

edit:

Clusters bestaan uit minstens 4 sectors ipv 2, dus 100MB ipv 50MB.

[ Voor 7% gewijzigd door Buffy op 16-03-2003 20:45 ]

[TD-er]

dat van het schrijven op een andere partitie had ik ook al over zitten denken. Probleem is echter wel dat je ook de partitietabel hebt, dus zal ik het geheel op een lege losse schijf moeten zetten. Ik heb nog wel een 6.4 GB die eventueel leeg mag dus dat is niet zo'n bezwaar. Dat ga ik dus van de week zeker ff proberen.
Tevens ga ik ook de no-error functie van dd en die rescue nog ff proberen.

Als er inderdaad nog een backup van de FAT op staat zou ik kunnen proberen met de hand de juiste sectoren naar een andere plek kunnen kopieren. Ik moet dan alleen wel weten van waar tot waar de FAT en z'n backup precies staan.
Heeft er iemand nog een overzicht van de precieze opbouw van een FAT16 partitie? Ik zal er zelf ook zo wel ff naar google'n...

Moet ik die jongen nog maar ff vragen om z'n drive mee te nemen, zodat we weer verder kunnen proberen de rotte stukken in te lezen....

[Buffy]

Deze pdf beschrijft de opbouw van de FAT filesystems. De voorbeelden zijn voor de floppy disk (FAT12) maar het kwa opbouw zijn FAT12 en FAT16 vrijwel het zelfde.

De opbouw is als volgt:

Boot sector
FAT1 sectors
FAT2 sectors
Root directory sector

De boot sector bevat (oa) de FAT grote maar als die beschadigd is kan je het beste opzoek gaan naar de root directory sector. De sector daarvoor is dan als het goed is de laatste sector van de backup FAT. De FAT grootte is dan de sector nummer / 2 (boot sector is nummer 0).

PS: Denk er aan integers zijn per 2 bytes opgeslagen met de minst significante byte eerst.

PPS: Ik zie dat je de image gemaakt hebt door /dev/sda te kopieren. Moet dit niet /dev/sda4 zijn?

[ Voor 8% gewijzigd door Buffy op 17-03-2003 00:07 ]