Záchrana dat z harddisku pomocí ZX Spectra.

[MaWa]

Tady se klidně nechám poučit, jak se to dá z těch čísel poznat.

je tam kolonka total LBA 48bit sectors...a hodnota je 00000 04769 40624. takže podle toho softu je tam 476940624*512bajtů dat...pokud toto číslo podělíš číslem 1024 na třetí , dostaneš kapacitu v gigabajtech...a moje windows kalkulačka mi píše 227.3GB...takový disk skutečně neexistuje, což je irelevantní...podstatné je, že to neodpovídá těm 160GB, co tam píšou...

Znovu opakuju, že nikdo neobnovuje zatuhnutej hdd bez resetu, nevím, jak jsi na to vůbec přišel. V tom článku se nic takového nepíše.

ale píše. sice ne explicitně, ale píše..."Ačkoliv se HDD v BIOSu identifikoval, číst z něj bylo zhola nemožné - zuřivě klepal a skřípal."...viděl jsem opravdu hodně vadných disků, ale nikdy jsem neviděl disk, který by zuřivě vrzal a skřípal, ANIŽ BY BYL VYTUHLEJ !!! prostě divný zvuky z disku = výtuh. tak to prostě je. tečka. a je to tak z jednoducháho důvodu - výrobci disků musí mít firmware co nejúspornější a zároveň co nejrychlejší...jim nejde o to, jestli po rozbití hlav/ploten ten disk ještě bude reagovat na okolí...raději pár kilobajtů ušetřených na nějaké exceptions vrhnou do optimalize cachingu apod...

víš co je možný ? já neřikám, že je to celý fake. ale možná si to trochu přikrášlili...možná ten disk nevydával žádný podezřelý zvuky...třeba jen selhal nějakej SW co použili...a tak si napsali svojí věc. budiž, to je možný...ale stále mi tam nesedí to lba...

kdyby tam nebyla tato věta viz výše, nikdy bych neřekl, že to je fake...přišlo by mi to divný (a asi bych nakonec zjistil tu chybu ohledně lba), ale nechal bych to asi být...

Měli disk, který v určité části nedokázal přečíst data, vzali ZX Spectrum a v assembleru udělali program, který dokázal detekovat vadný sektor a přeskočit ho.

ok, znova....JAK TEN SOFTWARE DETEKUJE VADNÝ SEKTOR PŘEDTÍM, NEŽ SE HO POKUSÍ PŘEČÍST ??? pokud se ho pokusí přečíst, tak JAK TEN SW DOKÁŽE DONUTIT DISK, ABY NEVYTUHL ???

Nevím o co ti pořád jde, jaký fandovství, abys udělal takovejhle software, tak musíš sakra umět programovat. To si myslíš, že si někde před měsícem koupili knížku o assembleru a pustili se z vesela do programování?

já nepsal že jsou fandové do assembleru, ale do zx spectra...a nijak nesnižuju to, jestli umí nebo neumí programovat v assembleru. o tom tato diskuse vůbec není...

Už jsem to jednou psal, tohle není Basic ani jinej jazyk s lehce pochopitelnou syntaxí, tady se tvrdě nadřeš, než se něco naučíš, ale výsledek stojí za to, protože pak máš pod kontrolou celej počítač a není pro tebe problém napsat program pro nějakou výstupní periférii přesně podle svých požadavků.

nikdy nemáš kontrolu nad jakýmkolivHW co má v sobě firmware...pokud nepřepíšeš ten FW...

Pokud nebyla chyba, provede se návrat instrukcí ret z, v opačném případě se pokračuje přečtením chyby a návratem. Pak už si můžeš vybrat, jestli chybu zapíšeš a pokračuješ rutinou, která posune hlavičku na další sektor a pak znovu sem a číst další, nebo vytvoříš smyčku řekněme 100 cyklů, která se pokusí o další čtení stejného místa.

ty ale stále předpokládáš, že tě ten disk poslouchá...ale on tě po prvním vadném sektoru přestane poslouchat...takže mu můžeš řikat co chceš v jakym jazyku chceš...

Prostě, na tohle stačí v pohodě stařičké ZX Specrum 48KB+starý řadič a nepotřebuješ ani megatunvé Windows ani drahý software, veškerá komunikace jde přes porty ...

já se s tebou nehádám, jestli přes porty nebo přes J2EE s net beans .NET frameworkem a oracle databází...
já jen prostě tvrdím, že z disku, který vydává nezvyklé zvuky (které oni tam popisují) softwarem nikdy nic nedostaneš...resp. dostaneš, ale ne tak, jak to tam popisují...

[johny128]

-----Original Message-----
From: jj [mailto:j-j@szm.sk]
Sent: Sunday, August 29, 2004 11:38 PM
To: blazek@8bc.com
Subject: clanok 11495 fake?

Dobry den

Mohli by ste mi potvrdit alebo vyvratit ci je clanok
http://www.cdr.cz/a/11495 pod ktorym je vase meno fake alebo ste to
mysleli vazne?
Kamarat co sa do diskov vyzna tvrdi ze je to fake, tak ako?

Vopred dakujem

------------------->>>
Dobry den,

v zadnem pripade to neni "fake".
Je to mysleno smrtelne vazne.
Disky se k ZX Spectru podarilo pripojit (pokud si projdete celou diskusi
najdete i nejake odkazy na web, kde jsou o pripojovani HDD k ZX podrobne
informace).
Vadny harddisk se podarilo naklonovat na zdravy a naprostou vetsinu
potrebnych dat nasledne zachranit pres Ontrack Easy Recovery.
Dam za to ruku do ohne.
Pekny den,

Martin Blazek

[Geeker]

Vadny harddisk se podarilo naklonovat na zdravy a naprostou vetsinu
potrebnych dat nasledne zachranit pres Ontrack Easy Recovery.
Dam za to ruku do ohne.

No tak nevim kdyz borci sami napsali ze data byla necitelna.

Hergot kdo se v tom ma vyznat

[Dony]

Vadny harddisk se podarilo naklonovat na zdravy a naprostou vetsinu
potrebnych dat nasledne zachranit pres Ontrack Easy Recovery.
Dam za to ruku do ohne.

No tak nevim kdyz borci sami napsali ze data byla necitelna.

Hergot kdo se v tom ma vyznat

tak si to precti jeste jednou a poradne

[Bathory]

výrobci disků musí mít firmware co nejúspornější a zároveň co nejrychlejší...jim nejde o to, jestli po rozbití hlav/ploten ten disk ještě bude reagovat na okolí...raději pár kilobajtů ušetřených na nějaké exceptions vrhnou do optimalize cachingu apod...

Souhlas.

ok, znova....JAK TEN SOFTWARE DETEKUJE VADNÝ SEKTOR PŘEDTÍM, NEŽ SE HO POKUSÍ PŘEČÍST ??? pokud se ho pokusí přečíst, tak JAK TEN SW DOKÁŽE DONUTIT DISK, ABY NEVYTUHL ???

To jsem napsal a popsal v tom zdrojáku předtím. Není to tak, že software napřed detekuje a potom čte, to jsem snad nikde nepsal. Software vydá příkaz k přečtení sektoru a buď se v pořádku načte a následně uloží jeho hodnota do paměti, nebo se čtení nezdaří a do paměti uložíš kód chyby.
Já tady nikde nevidím prostor na vytuhnutí (jedině výpadek elektřiny, či poškozená elektronika), ten může nastat například v případě, že je ten software naprogramován tak, že v někonečném cyklu se pořád dokola snaží přečíst onen sektor, ale tomu se oni samozřejmě vyhli a ani v tom zdrojáku, co jsem tam dal nic takového není. Neexistuje nic, než jednička a nula. Buď se čtení zdaří nebo ne a obě možnosti jsou ošetřeny.

nikdy nemáš kontrolu nad jakýmkolivHW co má v sobě firmware...pokud nepřepíšeš ten FW...

Souhlasím!

ty ale stále předpokládáš, že tě ten disk poslouchá...ale on tě po prvním vadném sektoru přestane poslouchat...takže mu můžeš řikat co chceš v jakym jazyku chceš...

Jestli má někdo zájem napsat software, který po přečtení vadného sektoru zkolabuje, prosím, je to proti přírodě, proti zdravému rozumu, ale tady záleží opravdu pouze a pouze na tom, jak to naprogramuješ.

já se s tebou nehádám, jestli přes porty nebo přes J2EE s net beans .NET frameworkem a oracle databází...
já jen prostě tvrdím, že z disku, který vydává nezvyklé zvuky (které oni tam popisují) softwarem nikdy nic nedostaneš...resp. dostaneš, ale ne tak, jak to tam popisují...

Je docela možný, že to přibarvili, aby to bylo zajímavější. Do mozků jim nevidím a na detektor lži je těžko dostanu.

[MaWa]

Já tady nikde nevidím prostor na vytuhnutí (jedině výpadek elektřiny, či poškozená elektronika), ten může nastat například v případě, že je ten software naprogramován tak, že v někonečném cyklu se pořád dokola snaží přečíst onen sektor, ale tomu se oni samozřejmě vyhli a ani v tom zdrojáku, co jsem tam dal nic takového není. Neexistuje nic, než jednička a nula. Buď se čtení zdaří nebo ne a obě možnosti jsou ošetřeny.

cvakání = mechanická závada raménka s hlavami...stále nevidíš důvod k vytuhnutí ? jak tomuto SW zabrání ? už víš, proč si myslim, že tak jak je to tam teď napsaný je to fake ?

Ale máš. Pokud napíšeš ovladač, který firmware nevyužívá.

to jako myslíš vážně ? to, že něco napíšeš v assembleru sice obejde operační systém a další věci, ale stejně nakonec JEN a POUZE ŘADIČ převede ten assembler na ata/atapi příkazy jako např. READ_DMA/MULTIPLE/SECTOR/EXT nebo WRITE_DMA/MULTIPLE/SECTOR/EXT...a tyhle příkazy přijme disk a disku bude jedno, jestli an druhý straně mu to vykládá software v assembleru nebo .NET aplikace...prostě blíž k disku s ani s assemblerem nedostaneš...chápeš ? to by sis musel napsat svůj BIOS řadiče a napsat svůj FIRMWARE disku ! a o ničem takovym tam nepíšou...

Vtip je v tom, že oni v tom assembleru udělali software, ovladač, kterej ke svý práci nevyužívá firmware onoho hdd! Prostě udělali program, kterej kromě komunikace s OS, sám komunikuje s hdd a řídí ho. Nic nového pod sluncem, už jsem psal o odstavec výš, že dřív se to ani jinak nedělalo. Oni nepřeflashovali firmware hdd, ale prostě ho ignorovali.

promiň, ale nelze ignorovat nebo "nevyužívat" firmware jakéhokoliv dnešního (čti méně než cca 10let starého) disku k jakékoliv operaci s ním. to je prostě fakt. tečka.
jediná vyjímka = přeprogramuješ si ho k obrazu svému...

ano, dříve to šlo...protože dříve disky neměly firmware ani PCB, a jak píšeš, o vše se starala "druhá strana" = řadič, ovladač, nebo jakkoliv tomu budeme říkat. ale dnes prostě firmware disku neobejdeš !!! to nejelementárnější, co s diskem můžeš dělat bez úpravy firmwaru je posílat mu jednotlivé ata/atapi příkazy. ale jak si je on (čti firmware/disk) zpracuje, je jen na něm...a pokud je mechanicky poškozen, tak se sekne. ano, můžeš si napsat svůj firmware pro disk, který bude jinak reagovat na případné chyb čtení nebo nějaké jiné, ale o tom v tom článku není ani slovo...a předpokládám, že kdyby se to stalo, tak by to napsali.

Jestli má někdo zájem napsat software, který po přečtení vadného sektoru zkolabuje, prosím, je to proti přírodě, proti zdravému rozumu, ale tady záleží opravdu pouze a pouze na tom, jak to naprogramuješ.

nezkolabuje SW, ale mechanicky zkolabuje ten disk !!! a je uplně jedno, jak to naprogramuješ. ve finální fází je prostě request na přečtení nějakého sektoru podle ata/atapi specifikace stále stejný, firmware ho stále stejně zpracuje, a hlavičky se stále stejně rozbijou...a těm mechanickejm hlavičkám bude jedno, jestli jim ten request poslal sw v assembleru, nebo .net aplikace zabírající několik megabajtů...

Je docela možný, že to přibarvili, aby to bylo zajímavější. Do mozků jim nevidím a na detektor lži je těžko dostanu.

já to vidím jako jediné možné řešení...i když i tak mi tam stále nesedí to lba...prostě kdyby smazali větu "disk vydával podivné zvuky a CVAKAL" = mechanická chyba hlaviček (nic jiného to být nemůže), tak neřeknu ani ň. ale takhle je to fake. sice částečný, ale fake. v dnešní době nelze obejít firmware disku. hloubš než na úroveň ata/atapi příkazů se nedostaneš ani s assemblerem. a i kdyby se dostali za firmware, tak stále je to mechanická chyba. na to ti SW nepomůže.

[johny128]

nechceli by ste tento prispevko FAQnut?myslim ze tolko kolko sa tuna vysvetlilo z oblasti diskov sa nepovedalo za celu existenciu fora


\\2m.h.l. => autorom som poslal obratom mail nech to sem pridu obhajit, pisali ze daju ruku do ohna za to ze to nie je fake, tak nech to dokazu

[mhl]

nechceli by ste tento prispevko FAQnut?myslim ze tolko kolko sa tuna vysvetlilo z oblasti diskov sa nepovedalo za celu existenciu fora

FAQovat určitě...ale co takhle sem pozvat ty autory toho článku at to tady sami obhájí...

[Bathory]

cvakání = mechanická závada raménka s hlavami...stále nevidíš důvod k vytuhnutí ? jak tomuto SW zabrání ? už víš, proč si myslim, že tak jak je to tam teď napsaný je to fake ?

Ale jo, když jim disk vytuhne na mechanickou závadu, je to v háji. To se ale zřejmě nestalo, jinak by ty data z disku nestáhli. Můj nejstarší Seagate 630Mb taky nejdřív cvakal a pak asi po 14 dnech totálně odešel. Holt to stačili udělat dřív, než se to úplně sesypalo.

to jako myslíš vážně ? to, že něco napíšeš v assembleru sice obejde operační systém a další věci, ale stejně nakonec JEN a POUZE ŘADIČ převede ten assembler na ata/atapi příkazy jako např. READ_DMA/MULTIPLE/SECTOR/EXT nebo WRITE_DMA/MULTIPLE/SECTOR/EXT...a tyhle příkazy přijme disk a disku bude jedno, jestli an druhý straně mu to vykládá software v assembleru nebo .NET aplikace...prostě blíž k disku s ani s assemblerem nedostaneš...chápeš ? to by sis musel napsat svůj BIOS řadiče a napsat svůj FIRMWARE disku ! a o ničem takovym tam nepíšou...

Ale prosím tě, řadič žádnej assembler nepřevádí. Assembler musíš zkompilovat do čistýho strojovýho kódu, teprve potom je funkční. Z assembleru můžeš normálně hdd ovládat přes porty, už jsem to psal a doložil zdrojákem. Nepotřebuješ k tomu žádnej firmware hdd. Co myslíš, že ten firmware je, je to normální binární kód zkompilovanej z assembleru, kterej udělal normálmí člověk z masa a kostí. Oni v tom svým ovladači mají samozřejmě dost věcí podobných s tím firmware, vždyť to dělá skoro stejnou práci. Akorát vypustili opravný algoritmy a podobný věci, který jim k ničemu nebyli.

promiň, ale nelze ignorovat nebo "nevyužívat" firmware jakéhokoliv dnešního (čti méně než cca 10let starého) disku k jakékoliv operaci s ním. to je prostě fakt. tečka.
jediná vyjímka = přeprogramuješ si ho k obrazu svému...

Taky promiň, ale myslím, že přes ty porty to lze.

a pokud je mechanicky poškozen, tak se sekne. ano, můžeš si napsat svůj firmware pro disk, který bude jinak reagovat na případné chyb čtení nebo nějaké jiné, ale o tom v tom článku není ani slovo...a předpokládám, že kdyby se to stalo, tak by to napsali.

Opravdu bude nejlepší, když je sem na fórum někdo dotlačí.

nezkolabuje SW, ale mechanicky zkolabuje ten disk !!! a je uplně jedno, jak to naprogramuješ. ve finální fází je prostě request na přečtení nějakého sektoru podle ata/atapi specifikace stále stejný, firmware ho stále stejně zpracuje, a hlavičky se stále stejně rozbijou...a těm mechanickejm hlavičkám bude jedno, jestli jim ten request poslal sw v assembleru, nebo .net aplikace zabírající několik megabajtů...

Já se opravdu nechci zastával mechanicky nefunkčního disku, ten nikdo nerozjede, to je snad jasný, o tom se nehádám ......

v dnešní době nelze obejít firmware disku. hloubš než na úroveň ata/atapi příkazů se nedostaneš ani s assemblerem. a i kdyby se dostali za firmware, tak stále je to mechanická chyba. na to ti SW nepomůže.

Zase mechanická chyba , tak po 150sátý, celou dobu píšu o čtení dat z vadných sektorů, disk se točí a hlavičky si vesele rajtují .... Help me, help me

PS: Škoda, že jsem nebyl na srazu, mohli jsme to rozebrat tam , nebo se tam rozebrat

[Bathory]

Čím víc nad tím tak přemýšlím a zjišťuju různý info z netu, tak si myslím, že by asi stačilo napsat normální ovladač bez opravných algoritmů, firmware disku zůstane zachován a normálně se použije, protože u funkčního disku opravdu není důvod, proč by nepřečnení sektoru, který je vadný mělo dojít k vytuhnutí. Vždyť i ty opravy se spouštějí po načtení či nenačtění určitý části. Kdyby disk vytuhl při pokusu načíst vadný sektor, není důvod, aby se s nima někdo programoval ...

Jak u svýho disku zjistím LBA číslo, že bych zkusil zpětný přepočet, jestli souhlasí.

[Geeker]

No tak nevim kdyz borci sami napsali ze data byla necitelna.

Hergot kdo se v tom ma vyznat

tak si to precti jeste jednou a poradne

Tady pisou ze Otázkou už jen bylo, zdali zachráněná data byla čitelná. Nebyla.

A pak to z toho vytahli utilitou

[MaWa]

1) dnešní odcházející disky se chovají trochu jinak než 630mb seagate, ale budiž, nechme to být...

2) prosimtě definuj mi, co si představuješ pod pojmem port...asi každý mluvíme o nečem jinym

3) hlavičky asi vesele nerajtují, když "Ačkoliv se HDD v BIOSu identifikoval, číst z něj bylo zhola nemožné - zuřivě klepal a skřípal."...myslíš, že skřípaly ty vadný sektory ? nebo mi teda řekni, co v tom disku zuřivě klepalo a skřípalo, když to NEbylo nic mechanického (tzn nic co by SW nedokázal odstranit)...

[MaWa]

Jak u svýho disku zjistím LBA číslo, že bych zkusil zpětný přepočet, jestli souhlasí.

je to napsaný na disku...alespoń ibm/hitachi to tak maj...ale ok, když mi nevěříš, spočti si to...

[Lemra]

Přečetl jsem si tu krásnou plamennou diskuzi a dovolím si vložit pár postřehů. Předem bych rád upozornil, že rozhodně nejsem expert v téhle problematice a to, co tady prezentuji, jsou jen moje domněnky. Takhle:

Podle mě není firmware disku nebo obecně třeba optické mechaniky nějaký dogma, tedy věc pevně daná. Nepochybně FW mechaniky využívají drivery při Large/LBA adresování (v tomhle okamžiku FW mechaniky překládá symbolické adresy na nativní adresy sektorů). Ale rozhodně existuje celá řada SOFTWAROVÝCH řešení, které umí ovládat přímo diskový řadič. Což v překladu znamená, že FW disku se musí umět přepnout do několika různých režimů. Třeba:

• nechvalně známé disky IBM řady tuším 80/120GXP odcházely tak, že POST je detekoval, ale potom už jen charakteristicky v rytmu chřoustaly a konec. Chrrr - cvak, cvak... chrrr - cvak, cvak... Při použití veškerých dostupných programů pro záchranu dat došlo k totálnímu zátuhu systému a nepodařilo se zkopírovat jedinej sektor. Ani pod DOSem s použitím jakýhokoliv DiskEditoru. Ovšem stačilo nabootovat z IBM disketky, obsahující jejich DFT, a řada disků po proběhnutí Fitness Testu (30minut cca) dodnes funguje (kupodivu) - mám ověřeno. Na dost discích a bohužel na řadě svých...

• opět utility výrobců disků - třeba Maxtor a jeho první ATA133 disky měly problémy s tehdejšími deskami s ATA100 řadiči. Utilitou lze disk (tedy logicky jeho FW) přepnout do ATA100/66 módu. Totéž platí dnes pro přepnutí na vysoký výkon/vysoký hluk... vše softwarově.

• abych tady neplácal jen nějaký domněnky, zavolal jsem před chvílí kamarádce z juda, která dělá dnes u PČR v Pardubicích na trestný činnosti související s počítačovými podvody - většinou řeší trapný pokusy, že PC byl napaden virem a účetnictví zmizelo, ale dělají i na jiných mnohem zajímavějších věcech. Kdysi jsem ji byl navštívit, maj tam celkem slušně vybavenou laboratoř... Potvrdila mě, že skutečně existují SW řešení, který dokážou číst z poškozených disků, u kterých je OK elektronika a motor. Mají ovšem techniku i na totálně odpálený disky, umí připojit vlastní pohon i elektroniku přímo na čtecí hlavy, prý dokonce umí tímto způsobem přečíst prakticky 100% dat i po provedení trojnásobného wipu...

• no a poslední věc - vypalovačky. Softy typu CCD přece taky obcházejí FW mechaniky z jednoduchých důvodů, FW rutina má třeby v popisu práce opravit vadný sektory, jenže to by zdrojové CD muselo splňovat příslušné specifikace dané příslušnými ColorBook. Protože ale "ochrana" specifikace porušuje, SW musí danou mechaniku znát a pokud to její FW umožní, soft musí ovládat přímo mechaniku bez rušivých zásahů FW, jinak vznikne podložka pod půllitr.

Ještě k Assembleru - kdysi jsem v něm (strašně nerad) programoval (byla to podstatná součást mé druhé maturitní zkoušky), ale je to fakt dávno... Dnes bych asi u jakékoliv primitivní úlohy neuměl ani ošetřit registry, ale kdysi jsem dokonce napsal pár her na PMD85 (fakt v assembleru, ne v BasicG - tedy třeba včetně zvuků...) a na první XT286 takovýho primitivního vira - jenom se množil, při každým stisku klávesnice na množení upozornil a připsal na disk kopii command.com s náhodným názvem. Takže za chvíli byl disk (tuším 120MB) plnej... prostě pakárna. To je jedno. Ale chci potvrdit to, co píše Bathory - veškerý interpretry současných vyšších jazyků samozřejmě zvládají překlad do strojových instrukcí daného mikroprocesoru, ale jazyk symbolických adres umí mnohem víc - zejména díky tomu, že lze využívat nedokumentované funkce. A že jich existuje... Jenom to chce někoho, kdo ví, co dělá...

[Bathory]

Taky jsem si ještě říkal, že mohli zkusit Low Level Format, mechanický chyby to sice neodstraní, to je jasný, ale s vadnýma sektoram by si to mohlo poradit.

2) prosimtě definuj mi, co si představuješ pod pojmem port...asi každý mluvíme o nečem jinym

Dobrý, ale fakt jsem neměl na mysli sériovej či paralelní. Přesnou definici ti nedám, ale lze si ho představit jako vstupně výstupný registr in/out, který má přiřazenou spec. adresu pro komunikaci s výstupním zařízením. Když se podíváš na ten zdroják, najdeš tam několik instrukcí in a,(číslo) nebo out(číslo),a.
Ten zdroják byl napsanej k rozhraní IDEFACE, kterej ZX rozšířil ZX o 8 portů, nebo taky registrů IDE:
data reg................................R/W
error/status reg......................error=R, status=W
count sec reg.........................R/W
sector reg..............................R/W
cylinder low reg.......................R/W
cylinder high reg......................R/W
device/head reg.......................R/W
status/command reg.................status=R, command=W

3) hlavičky asi vesele nerajtují, když "Ačkoliv se HDD v BIOSu identifikoval, číst z něj bylo zhola nemožné - zuřivě klepal a skřípal."...myslíš, že skřípaly ty vadný sektory ? nebo mi teda řekni, co v tom disku zuřivě klepalo a skřípalo, když to NEbylo nic mechanického (tzn nic co by SW nedokázal odstranit)...

Já jsem nikdy neslyšel disk skřípat, klepat jo, ale skřípat?
Škoda, že se to LBA nedá zjistit jinak, otevřel jsem bednu, ale co je napsáno navrchu hdd nepřečtu, je to schovaný a odpojovat disky a vyjíždět s kolejnicí se mi qůly takový kravině nechce, když tak příležitostně. Ten Seagate 630MB to na sobě napsaný nemá, tomu se ale nedivím.
Jinak mám 80GB Maxtora 8MB a Seagate 4,3GB.

Věřím tomu, že některá jejich interpretace asi byla trochu OUT, ale na netu jsem narazil na pár maníků, kteří k ZX harddisk skutečně připojili a používali, či používají dodnes.

[MaWa]

předpokládám, že ten příspěvek od Lemry byl adresován mně, takže na něj zareaguji

ad 1. odstavec...velmi nerad bych se pouštěl do polemiky o nečem, čemu teda fakt moc nerozumim a tím jsou optické mechaniky a to jak fungují. přesto si ale myslím, že srovnávat optické mechaniky a jejich FW s diskem a jeho FW je dost mimo. už jenom třeba proto, že fw do optik se flashují jak na běžícím pásu, existují pro to různé hacky (dvd regiony apod)...pokud by to bylo stejné jako disky, proč na disky už dneska není milion utilit pro změnu bůhví čeho ?
fw disku se už z principu nesmí nechat snadno změnit a už vůbec obejít...a proč ? no třeba proto, že ata/atapi-7 specifikace používá věci jako zaheslování disku na HW úrovni disku...a to je velmi dobrá ochrana dat, která by asi ale byla plně na nic, kdyby šlo ten FW disku, který se o kontrolu hesla stará, nějak více či méně snadno obejít...to prostě není přípustné.
navíc...ok, připusťme, že tedy nějak obejdnete FW disku a dostanete se přímo k ovládání hlaviček a ploten...pak by Sw který tady napsal Bathory (jako příklad) stejně nefungoval, protože jaksi by musel napsat celý SW pro pohyb hlaviček (protože by jimi už nepohyboval firmware disku)...takže hezky všechny head movements, servo data checking, inicializace, read/write states atd atd...protože tam už neni žádný "najeď na lba 123456 a přečti to a když se ti to nepovede naje´d na další a když se ti to povede tak mi to pošli"...

ad 2.odstavec...o tom zprovoznění pomocí IBM DFT slyšim poprvé v životě je to někde i zdokumentováno na internetu ?

ad 3.odstavec...ano, jsou editovatelné a změnitelné části firmware disku...a je jich dost (max kapacita, aam, dma mody,...). ale to jsou vše jen parametry, nelze softwarově editovat samotný FW (program)...jinak než přeflashnutím....a i to v podstatě neni tak easy jak se zdá, protože výrobci se tomu brání seč to jde

ad 4.odstavec...já netvrdím, že to nejde...sám jsem tuším na první stránce popsal postup, jak to v zásadě udělat...ale ten postup je silně jiný než to co popisují v článku...třeba proto, že bez několikanásobného restartu to imho nejde (alespoň mě teď nenapadá jak)...pokud si neuděláme vlastní firmware, který by reagoval na krizovou situaci jinak než zatuhnutím...
jen s jedním nesouhlasím...další bubák...sorry, ale ani jednonásobný wipe (zero fill) ničím v reálně snesitelné době neobnovíš, pokud nemáš detailní informace o tom, co na tom disku (a kde na tom disku) bylo...nebo nejsou splněny další speciální věci, o kterých jsem tady snad nedávno v polemice (s mihem ?!?) psal...resp. obnovíš, ale nemůžeš si být jist, že to, co se obnovilo, je to, co tam opravdu před zero fillem bylo.

ad 5.odstavec...viz výše o FW optik..

ad 6.odstavec...nikdy jsem neslyšel o tom, že by existoval byť jen jeden jediný nezdokumentovaný ata/atapi příkaz...pokud takový existuje a lze díky němu obnovovat data, nechápu, proč by byl nezdokumentovaný
taktéž pochybuji, že existují nezdokumentované funkce samsung pevných disků, resp. jeho firmwaru....resp. takové funkce, které by nějak pomohly se záchranou dat z dotyčného disku.


ale nechal bych celou tuto kauzu být, nemá to cenu....
jediné, na čem jsme se snad shodli je to, že je chybný počet LBA v tom screenu...což je více než podezřelé...a dál bych to snad ani neřešil. peace...

[MaWa]

ještě reakce na Bathoryho...tak ok, oba asi myslíme to samé...prostě něco jako "rozsah I/O"...ovšem bohužel disk nemá žádný rozsah I/O, neboli port. port má jen řadič, na kterém je disk pověšený. ovšem je pravda, že se to může tvářit jako že rozsah I/O má disk, a ne řadič. ty IDE registry jsou klasický, ale tím ovládáš pouze řadič...ať se to tváří jak chce...neovládáš tim disk,a už vůbec tim neobcházíš firmware...ten je ještě daleko za tím.

tim skřípaním asi mysleli takový ten kovový zvuk...něco jako dělaj seagate barča 7200.7 sata nebo 7k250ka (občas)...

pokud se chceš přesvědčit o tom LBA, podívej se třeba na stránky hitachi, tam je u každýho modelu v datasheetu napsáno, jakou má kapacitu a jakej má počet LBA. a nemusíš lézt do bedny. a LBA je vždycky 2x větší než kapacita disku v kilobajtech...

[Bathory]

Je fakt, že na dnešní disky se za posledních pár let nabalilo tolik nových technologií, že ty starý asi kliďánko mohli jet bez firmware, ale tady to bude problém. Trochu jsem ten firmware podcenil, ono najít co všechno obsahuje není zrovna nejlehčí a ani do teď se mi to na 100% nepovedlo, ale je toho docela dost.

Jinak ten zdroják samozřejmě není kompletní, ale mám za to, (platí, že expert na hdd tady seš pořád ještě ty) že ty pohyby hlaviček, roztáčení motorku atd. by měla obstarávat elektronika hdd, software pouze zadá vstupní údaje.

Ještě k těm tajným instrukcím, Lemra nejspíš myslel tajné instrukce assembleru a ty skutečně existují.

[MaWa]

Jinak ten zdroják samozřejmě není kompletní, ale mám za to, (platí, že expert na hdd tady seš pořád ještě ty) že ty pohyby hlaviček, roztáčení motorku atd. by měla obstarávat elektronika hdd, software pouze zadá vstupní údaje.

Ještě k těm tajným instrukcím, Lemra nejspíš myslel tajné instrukce assembleru a ty skutečně existují.

roztáčení motorku má opravdu na starosti elektronika, ale ne už pohyby hlaviček...resp. jejich správné umístění nad daný požadovaný cluster....v dnešních discích se používá embedded servo data, která jsou umístěna všude po disku mezi daty a když se seekuje, tak hlavička tyhle data čte, předává je servu (v podstatě část FW, ale uplně oddělená a nikdy neflashovatelná) a servo to vyhodnotí a ví kam až se musí seeknout a upraví podle toho trajektorii hlaviček. celá tato technologie/operace byla vymyšlena IBM, a IBM/Hitachi je v tomto stále nejlepší - proto mají jejich disky nejlepší seek time.

o tajných instrukcích assembleru nebudu polemizovat, protože je to pro mě španělská vesnice...ale určitě to nebude nic co by mohlo mít něco společného s tímto tématem...

[johny128]

nebo nejsou splněny další speciální věci, o kterých jsem tady snad nedávno v polemice (s mihem ?!?) psal...

http://forum.pctuning.cz/viewtopic.php?t=14286