nalezeni souboru na disku podle LBA

Dan Lukes dan at obluda.cz
Thu Sep 24 10:53:41 CEST 2009


Miroslav Lachman napsal/wrote, On 09/24/09 08:20:
> snad nevadi, ze pisu primo a ne do konference.

Ja myslim, ze by to mohlo zajimat i nekoho jineho. Tak snad nevadi, ze 
odpovim i do konference. Odstranil jsem z toho vsechno, u ceho byt' jen 
trochu pripada v uvahu, ze by ti zverejneni mohlo vadit.

> Pamatuju si, ze jsi tam jednou resil podobny problem

To byl thread, ktery konci touhle zpravou

http://www.freebsd.cz/listserv/archive/users-l/2006q1/015961.html

Jak jsem psal uz tam - sleuthkit se mi nakonec nejak pouzit nepodarilo.

> Vcera me na jednom v podstate novem serveru potkal problem s 
> necitelnosti jednoho sektoru. 

> V logu mam nasledujici informace:
> GEOM_MIRROR: Device gm0: rebuilding provider ad6.
> ad4: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=79725056 
> GEOM_MIRROR: Request failed (error=5) ad4[READ(offset=40819228672, length=131072)]
> GEOM_MIRROR: Synchronization request failed (error=5). mirror/gm0[READ(offset=40819228672, length=131072)]

> Znam tedy LBA=79725056 a znam ad4[READ(offset=40819228672, length=131072)]  (ackoliv nevim tak uplne presne, co to znamena)

Napovim ti:

40819228672 / 512 = 79725056

"length" pak rika, ze slo o pozadavek na cteni 256 sektoru

> Dokazal bys mi k tomu rict, jakym konkretnim postupem zjistim, na jake 
> partition tato oblast lezi a jaky se v ni nachazi soubor / soubory. 
> Pripadne jak tenhle sektor zkusit znovu precist / prepsat?

Ono je to u tebe jeste o dost slozitejsi nez u me. Ja mel FS skutecne n 
atom disku. To ty ale nemas - ty mas FS na virtualnim disku gm0. Oproti 
me tedy, nez prepocitas znamou polohu ve slice na oznaceni konkertniho 
souboru, musis jeste prevest udaj o fyzicke lokaci na udaj o lokaci v 
ramci toho virtualniho disku. Sice "mirror" - to je pro tyto ucely asi 
ten nejednodussi scenar, ale i tak. A skoro jiste ti s timhle nepomuze 
sleuthkit (i kdyz od nekoho, kdo se snim nenaucil zachazet muze tak 
kategoricke tvrzeni znit odvazne).

Otazka ale je, nakolik to bezpodminecne nutne potrebujes vedet.

Abych pravdu rekl, ja jsem se v techto pripadech obvykle spokojil s tim, 
ze jsem si vynutil interni relokaci (aby problem zmizel) a nasledne jsem 
zupgradoval jak system tak porty (upgrade OS ze stejne verze na stejnou, 
u portu totez). Je to zalezitost na hodinku maximalne dve a nevyzaduje 
to lidskou pozornost. Pripadalo mi to ve vysledku daleko mene prace.

Poskozeny tak mohou byt maximalne konfigurace na coz by se melo pomerne 
rychle prijit a nebo uzivatelska data, ktera tam ale momentalne asi 
nemas (a ja obvykle nemam uzivatele vubec i kdyz vyjimky se najdou)

Ale u tebe by to mohlo jit bezbolestneji - pokud ten ad6 neni cerstve 
pridany prazdny disk a alespon jednou uz byl v synchronizovanem stavu, 
pak je vysoka pravdepodobnost, ze na pozici LBA 79725056 az +256 je ve 
skutecnosti spravny a citelny obsah. Pak by stacilo rucne prekopirovat 
tuto oblast z ad6 na ad4 (dd) coz by soucasne vynutilo relokaci a bylo 
by vyreseno. Respektive, je zbytecne prekopirovavat vsech 256 sektoru. 
Nejprve ctenim na ad4 izoluj ktery presne sektor to je. Pulenim 
intervalu to mas na osm pokusu. Pak vyres ten jeden jediny sektor (po 
vyreseni je treba znovu precist celou 256 velkou oblast abys overil, ze 
tam neni jeste dalsi problematicky sektor).

Ano, uvedomuji si, ze riziko, ze pri prekopirovavani ad6->ad4 nemusis 
spravny obsah ziskat. Pokud to riziko neuneses, nebo ad6 nikdy 
synchronni nebyl, pak je tu furt ta zdlouhavejsi metoda zminena vyse.

Stejne je pro tebe zasadnejsi to, ze produkcni server s takto se 
chovajicim diskem je problem a budes muset rozmyslet, jestli je to 
naprosto nahodna fluktulace, nebo jestli radeji disk vymenis.


						Dan


P.S. Jak jsem tehda hartusil, ze 15 relokovanych sektoru za 8400 
provoznic hodin je hodne - tak ten pocet sektoru vystoupal pomerne 
rychle na desetinasobek. Pak Western Digital priznal chybu ve firmware 
disku, dodal update a od te doby cislo najednou zazracne rust prestalo. 
Tykalo se cele rady WDxxxxYS
http://support.wdc.com/product/download.asp?groupid=605&sid=57&lang=en




More information about the Users-l mailing list