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