nalezeni souboru na disku podle LBA

[Dan Lukes]

Miroslav Lachman napsal/wrote, On 09/24/09 15:43:
>>> 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 
>> na tom disku. To ty ale nemas - ty mas FS na virtualnim disku gm0. 
>> Oproti me tedy, nez prepocitas znamou polohu ve slice na oznaceni 
>> konkretniho souboru, musis jeste prevest udaj o fyzicke lokaci na udaj 
>> o lokaci v ramci toho virtualniho disku.

> Pokud je ten mirror gm0 slozen primo z disku ad4 a ad6, tak by mel 
> pokryt celou oblast disku krome posledniho sectoru, ale zacatek bude mit 
> stejny, nebo se pletu? Nejak tam nevidim zadny duvod k tomu, aby mirror 
> a nad nim udelane slices a partitions byly o neco posunute, nez kdyby 
> tam byl samotny ad4

Jak sam rikas - melo. Nezkoumal jsem presnou vnitrni implementaci 
gmirror, takze nevim. Over si svoje tvrzeni - precti par sektoru z gm0 a 
par z ad4 a pokud bude obsah stejny (zkus se netrefit do prazdneho mista 
a vynulovanych sektoru).

Kdyz overis, ze prepocet je fakticky identita potvrdia tim i moje 
tvrzeni, ze ten prepocet bude jednoduchy.


>> Otazka ale je, nakolik to bezpodminecne nutne potrebujes vedet.
> 
> Zivotne dulezite to neni, vzdy je tu moznost - disk vyhodit a cely 
> system nainstalovat a nakonfigurovat znovu na jiny disk... ale pokud 
> bych dokazal rozumnym postupem zjistit, ktereho souboru se to tyka, 
> usetrilo by mi to hodne prace. 

Ja mluvil o riziku, ze prepises soubory, ktere je snadne prepsat 
(instalace OS a portu), zbytek ponechas a uneses zbytkove riziko, ze 
poskozeny je nektery z neprepsanych souboru.

> Krome systemu a portu tam je uz pomerne 
> velka MySQL databaze (InnoDB cca 8GB data file + binlogy pro replikaci). 
> V tomto konkretnim pripade bych tedy spis potreboval najit jistotu, ze 
> tahle databaze neni poskozena

Databazi 's tam odnekud nakopiroval nebo je prazdna. V obou pripadech by 
nemel byt problem ji smazat a obnovit. Pokdu mas tabulky vytvorene s 
checksumem tak by poskozeni mel zdetekovat uz databazovy engine. A 
nakonec - staci provest kompletni dump (treba na /dev/null) - pokud se 
povede tak databaze poskozena neni.

> obecne by se mi asi hodilo, znat postup, *jak zjistit soubor podle pozice vadneho bloku*.

Taky by se mi obcas hodilo. Bohuzel, neznam.

> Mam v planu zkusit vynutit realokaci prepisem toho sektoru, ale to az v 
> pripade, ze zjistim, co na tom sektoru lezi, nebo ze tam nic nelezi.

Nejprve dohledej ktery z tech 256 sektoru ve ctenem bloku to byl. Pak 
muzes zkusit nahlednout jeho obsah. Asi ne primo, protoze pokud sektor 
cist nelze, obvykle ti to nevrati ani castecny obsah, ale same nuly.

Takze spis budes muset zkouknout ty sektory okolo a verit, ze patri do 
jednoho alokacniho bloku. I tak ale nahlednutim do obsahu nezjistis 
spolehlive co (a zda neco) sektor pouziva.

V kazdem pripade budes muset nejprve prevest pozici na fyzickem disku na 
pozici v ramci slice (trivialni matematika - zjistis, kde partition na 
fyzickem disku zacina a odectes) nasledne budes muset zaridit podobny 
prepocet (podobnym algoritmem) pri prechodu z slice do partition. A zde 
koncime - pozici v ramci FS na soubor proste prevest neumim. ZKus 
zmermomocnit ten port o kterem byla rec - treba z nej neco dostanes. Me 
se ho nejak zdolat nepovedlo.

> Docela by me zajimalo, jak to s temi realokovanymi sektory je u 
> jednotlivych vyrobcu / modelu HDD. Na nekolika systemech se mi cca po 
> roce provozu objevil treba jeden "pending sector", prepsanim celeho 
> disku zmizel, ale ve SMARTu se nenavysil counter realokovanych sektoru. 
> Na jednom systemu se dokonce tenhle pending sector porad objevuje, po 
> kazdem prepisu disku na cas zmizi a pak se zase objevi, ale 
> Reallocated_Sector_Ct i Reallocated_Event_Count maji porad nulovou 
> hodnotu.  Tak jestli se to nahodou vyrobci nesnazi jeste nejak nepekne 
> maskovat.

Vyrobci maji v tomto ohledu zcela volne ruce. Zaprve co se tyce 
algoritmu urcujicim "sektor ma byt relokovan". Mohou napriklad do 
sektoru zapsat (i kdyz nejde precist) a pokud se zapis s verifikaci 
povede vyhodnoti sektor jako dobry. Jini prehodnoti nazor napriklad 
tehdy, kdyz se pri opakovanem cteni sektor podari precist.

Zadruhe - vyznam RAW i COOKED hodnot v ramci SMART neni standardizovan. 
Urceno je v zasade jedine - dokud je COOKED hodnota vetsi nez TRESHOLD 
tak je vse OK, pokud je mensi znaci to problem. Fakticky vzato tak 
"relocated sector count" muze ukazovat porad stejnou vysokou hodnotu a 
vesele relokovat a kdyz mu sektory k relokaci dojdou, muze skokem 
prepnout na ukazovani nizke hodnoty. Nebude to poruseni specifikace.

A v neposledni rade - pokud vim, tak v poslednich specifikacich uz neni 
snandardizovano ani to, co ten-ktery atribut globalne znamena. Takze - i 
kdyz zjistis, ze attribut 5 je pod urovni threshold vis s jistotou 
akorat tolik, ze NECO je spatne. Neni ale standardni zpusob jak zjistit co.

Proste - bez vendor-specific interpretace hodnot toho SMART prozradi 
opravdu dost malo. Takze je treba davat pozor - neni zaruceno ani to, ze 
vsechny disky jednoho vyrobce k veci pristupuji stejne (nejiste zejmena 
po akvizicich) a v neposledni rade se vyznam muze menit dokonce i pri 
vymene firmware. Nejmene teoreticky.

					Dan