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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
