strasi?

Petr Stehlik pstehlik na sophics.cz
Neděle Říjen 21 10:33:35 CEST 2007


Pavel Kankovsky píše v So 20. 10. 2007 v 18:41 +0200:

> > ma nekdo nejakou predstavu, jak se muze dostat kus syslogu do /etc/motd?
> > Vypada to pak asi takto:
> 
> Podle obsahu je zřejmé, že se to tam objevilo těsně před rebootem.

to si nemyslim - obsah toho pripojeneho kusu syslogu zacina naopak tesne
po rebootu (restartoval jsem v 00:14:xx po instalaci noveho kernelu) a
konci to zaznamem z 06:28, coz je bezny logrotate (u Debianu zacina
cron.daily v 06:25). Takze mi to prijde, ze ten motd byl poskozen pri
logrotate...

> Pokud ale máte ext3 s data!=writeback, tak by nic takového nikdy nastat 
> nemělo.

mam ext3 s default (coz ted nevim, jestli je = nebo != writeback).

> Také by to v principu mohlo nastat, kdyby se nevhodným způsobem pomotala 
> data v paměti a stránka s kusem motd by se při zápisu zaměnila za stránku
> s se skutečnými daty. Máte paměť s ECC?

bohuzel nemam, a mrzi me to. Priznam se, ze jsem tuto situaci na stejnem
stroji uz zazil a memtest i neco nasel, ale to se resilo reklamaci
pameti a tentokrat rychly memtest nic nenasel. Ale je fakt, ze za pul
hodiny nemusi mit memtest zadne "stesti" na vadny bit. Ovsem v pondeli
dopoledne jsem nemel vic casu, viz nize.

> > neco tam pravda nasel, ale nevim presne co, protoze jsem to fsck zkousel 
> > poustet vickrat s ruznymi vysledky.
> 
> Tak to je zajímavé. Ale pokud ty výsledky nemáte někde schované, tak 
> z toho těžko něco vyvozovat. Našel jste nějaké další poškozené soubory?

Problem je, ze jsem si chvili myslel, ze muzu provadet fsck -n za behu
systemu a neco z toho vyvozovat. Takze to vysypalo hromady problemu,
ktere jsem se snazil resit a moc se divil, ze potom, po rebootu do
single a remountu r/o uz se neobjevovaly. A protoze okolo neustale
chodili lide s otazkami "kdy uz to pojede", nepostupoval jsem zrovna
systematicky, bohuzel.

Kazdopadne co si vybavuju, tak nejdriv jsem to zkusil jednoduse -
kombinaci -c 1 -C 2 u tune2fs jsem zaridil, ze pristi reboot se
filesystem zkontroloval sam, poprve po 11 mesicich, a nasel nejake
drobne problemy (uz nevim jake), opravil je a pak napsal: "filesystem
stale obsahuje problemy, restartuji". V tu chvili jsem si myslel, ze
zertuje. Pak jsem si dalsi chvili myslel, ze restartuje proto, aby ty
problemy doopravoval pri fsck po tom rebootu. Ovsem on uz se zadny dalsi
automaticky fsck nekonal. Pak jsem podnikal chvili pokusy s fsck -n na
zivem filesystemu (coz me dokonale zmatlo) a potom jsem konecne prozrel,
premountoval v single na r/o a napjate pustil fsck, ale ten tentokrat uz
nic nenasel. Jak to souvisi s tim, ze "filesystem stale obsahuje
problemy, restartuji" netusim - budto predtim nebo ted mi nerikal
pravdu.

> Ono to bude ještě horší, jelikož množství uložených dat rychle roste, ale 
> pravděpodobnost jejich poškození na jednotu objemu dat a času zas tolik 
> ne, a tudíž očekávaný objem poškozených dat roste také celkem rychle.
> (Zkuste si někdy vynásobit kapacitu běžného desktopového disku 
> s deklarovanou pravděpodobností výskytu chyb a podívat se, co vyjde.)

No prave - me ted naramne zajima, jak vlastne ty filesystemy
kontrolovat... Uz vim, ze se muzou poskodit, kdyz se server necha jen
tak bezet - mam snad restartovat kazdy mesic o pulnoci s tim tune2fs -c
1, aby se filesystem zkontroloval? Jak vysvetlim tech nekolik desitek
minut az hodin nedostupnosti sluzeb?

> > Googloval jsem, jak kontrolovat ext3 za normalniho behu systemu, ale 
> > zrejme to bez LVM snapshotu nepude.
> 
> Ještě můžete udělat remount na read-only, ale to jste asi nechtěl
> slyšet. :)

vetsinou se remount na r/o za bezneho provozu stejne neda provest, takze
tahle rada mi moc nepomohla ;-)

Petr





Další informace o konferenci Linux