nalezeni souboru na disku podle LBA (fsdb findblk)

Dan Lukes dan at obluda.cz
Mon Oct 5 16:13:44 CEST 2009


Miroslav Lachman wrote:
>>> Jenze s fsdb mam takovy problem, ze i kdyz najdu nejaky soubor 
>>> (inode), necham si k nemu vypsat bloky a pak tyto bloky zadam zpet 
>>> fsdb findblk, tak mi zadny inode nevypise. 
>>
>>
>> No to je proto, ze fsdb je velmi zmatene. Kdyz pouziva pojem "blok" 
>> tak tim nikdy nemysli blok - nejcasteji tim mysli blok ale fragment. A 
>> v pripade findblk pak dokonce mysli sektor.

> ad6: FAILURE - READ_DMA status=51<READY,DSC,ERROR> 
> error=40<UNCORRECTABLE> LBA=22832527

Tak zaprve je treba dohledat presne cislo sektoru. Uz jsem tady nekdy 
asi zminoval, ze v pripade cteni vetsiho poctu sektoru je uvedeno cislo 
prvniho sektoru v sekvenci. Sekvence muze byt az natolik dlouha, ze muze 
presagovat nekolik fragmentu  ctena data tak mohou patrit i ruznym souborum.

Takze zakladem je pouzit "dd" a najit presne cislo toho jednoho vadneho 
sektoru. Teprve na takto ziskane cislo je treba aplikovat dalsi postupy.


> fdisk (zkraceny vypis):
> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
>     start 63, size 125821017 (61436 Meg), flag 80 (active)
> 
> bsdlabel (zkraceny vypis):
>   d: 12582912 12582928    4.2BSD     2048 16384 28528
>   e: 83886080 25165840    4.2BSD     2048 16384 28528

> Od LBA chyby odectu offset prvni slice (63)
> 22832527 LBA error - 63 = 22832464
> 
> A od toho pak jeste offset partition /var
> 22832464 - 12582928  = 10249536
> 
> Tim jsem ziskal pozici chyby uvnitr partition /var

A oba kroky je trivalni overit. Znas offset na ad6, jehoz cteni se 
nedari. To, ze mas vypoctenou spravnou pozici v ramci /var zjistis 
pokusem o precteni vypocteneho offsetu z /dev/mirror/gm0s1d

Nemelo by to jit.

> Pokud jsem te pochopil spravne, mel jsem ziskane cislo vynasobit 4

Ne - nepochopil. Ty uz mas cislo sektoru - tedy cislo pro findblk. Ja 
ale reagoval na tvoji vetu "i kdyz najdu nejaky soubor (inode), necham 
si k nemu vypsat bloky ..."

Ty "vypsane" bloky nejsou cisla sektoru, ale cisla fragmentu - a ty bylo 
treba vynasobit ctyrmi.

Tady ale velikost sektoru uz mas a tudiz prepocitavat nemusis.

> fsdb (inum: 2)> findblk 10249536
> 10249536: data block of inode 23704
> prikazem find pak slo dohledat o jaky soubor se jedna
> 
> ~/# find /var/ -inum 23704
> /var/log/lighttpd/lighttpd-error.log

A znovu muzes vyzkouset - pri cteni tohoto souboru by mela vyskocit 
chyba cteni. Pak vis, ze mas spravny soubor.

> jen mi porad nejde dohlavy, proc se tam pokazde pracuje s jinymi bloky a 
> co tim autor fsdb sledoval... zrejme zmateni nepritele.

Ale, ani ne. To je spis neumyslna terminologicka chyba.

Blok - to je stejny problem jako je "paket" v sitarine. Podle toho, na 
kterou vrstvu sitoveho stacku se podivas, tak je paket trochu neco 
jineho, ma jinou aktualni/maximalni velikost. I "destination address" 
znamena neci uplne jineho v ethernetovem paketu a neco jineho v IP 
paketu. Ve skutecnosti ma kazda vrstva jednoznacne pojmenovani pro 
"paket" (na TCP urovni je to "segment", na IP urovni "datagram" na 
ethernetu "frame"), ale bezne (a to i v odborne mluve) se velmi casto 
pouziva genericky (a nepresny) pojem packet. Ono totiz ke zmateni dojde 
jen v pripade, ze neni jasne o jake vrstve je rec, coz vetsinou byva.

A tady to mas totez. Blok je "packet" diskoveho systemu. A na kazde 
urovni "blok" znamena neco jineho. Jednou sektor, jednou fragment, ...

Jo, jakmile program umi pracovat s bloky ruznych vrstev je pouziti pojmu 
"blok" problematicke. Posli navrh na zmenu prislusne manualove stranky ;-)

						Dan



More information about the Users-l mailing list