Dan Lukes wrote:
Miroslav Lachman napsal/wrote, On 09/24/09 08:20:
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.
Vubec nevadi...
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
Aha, tak tady uz se zacinam trosku chytat
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).
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
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. 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, ale obecne by se mi asi hodilo, znat
postup, *jak zjistit soubor podle pozice vadneho bloku*.
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
Tohle je ten problem, ad6 obsahuje testovaci data uplne jine instalace,
takze na 100% nelze zkopirovat ani kousek dat z ad6 na ad4. :(
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.
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. Pak
disk zkusim jeste parkrat precist a kdyz dojde k dalsimu problemu, pujde
pryc a nahradim ho novym. Pripadne ho rovnou nahradim jinym (podle toho,
jak bude tlacit cas na uvedeni do produkce)
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
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.
Mirek
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
