Történt ugyanis, hogy a RAID1 egyik komponense úgy döglött meg, hogy annak kifelé nem volt nyoma. SMART hibatároló üres, és maga a diszk sem jelez I/O hibát, sőt, semmit sem, úgy tesz, mintha minden oké volna. Ennek megfelelően a RAID vezérlő sem dobta ki a komponenst, és állította a tömböt degradált módba. Az írási műveletek szépen lefutottak, az egyik komponensre jó adatok kerültek, a másikra meg néha nem. Olvasáskor pedig a RAID1 nem olvassa párhuzamosan mindakét komponenst, így nem derült ki a turpisság. Az archiváló rendszer meg több, mint egy hete vígan mentegeti az itt-ott hibás adatokat...
Happy end persze van. A rossz komponens kidobása után a RAID1 másik lábán nagyjából ott van majdnem minden frankón, kivéve azokat a fájlokat, amit a problémás időszak alatt (kb. 1,5 hét) beolvastak a tömbről, és visszaírták módosítás után. Szerencse a dologban, hogy a probléma csak nagyobb I/O műveleteknél jelentkezett, tehát pár kByteos dokumentumok rendben, csak 20-30 mega feletti ojjektumokkal van gond, abból meg az utóbbi időben nem volt nagy mozgás. (valószínűleg ennek köszönhető, hogy nem kaptak fájlrendszer-pánikot sem - bár lehet, hogy jobb lett volna, ha kapnak, mert akkor nem húzzák ki vele másfél hétig, hanem egyből összeomlik a katyvasz.)
Az elmúlt időszak hibás mentései persze kuka, de ez legyen a legnagyobb bajunk...
Legközelebb majd ZFS-t rittyentünk ext3 helyett, checksum enabled, aztán legalább eladok nekik egy új vasat is a megnövekedett hardverigény miatt :P (Ja, meg RAID5-öt használunk RAID1 helyett, mert az remélhetőleg mindig benyalja az adatok mellé a paritást is, hehhe)
Azért 22 éve mókolok számítógépekkel, de ilyet még nem pipáltam. A diszk a korongról olvasásnál checksumol. A SAS busz adatátvitelnél szintén...
- mauzi blogja
- A hozzászóláshoz be kell jelentkezni
- 1663 megtekintés
Hozzászólások
cool story 1998-ból, szerencsére ma már van ZFS :)
- A hozzászóláshoz be kell jelentkezni
Azt mondta az Orákulum, hogy nem NeoTux a kiválaszott...
- A hozzászóláshoz be kell jelentkezni
"SMART hibatároló üres, és maga a diszk sem jelez I/O hibát, sőt, semmit sem, úgy tesz, mintha minden oké volna"
Nekem volt egy ilyen WD Caviar Green merevlemezem, videófájlok tárolására használtam, a WD állásfoglalása alapján megpróbálkoztam a wipeolásával, de továbbra is CRC hibásan másolt fel minden egyes állományt.
- A hozzászóláshoz be kell jelentkezni
RAID1-ben tárolom a fontos adatokat és rendszeresen mentek. Emiatt is érdekel a történeted. Örülök, hogy szépen ki lehetett jönni belőle.
3ware-nél van egy ilyen feature, hogy autoverify. Mondjuk lassítja a rendszert még akkor is, ha maximum IO-ra van konfigolva.
A ti frankó RAID vezérlőtökön nem volt valami auto-verify lehetőség? Vagy azon is átcsúszott a hiba? Mert elvileg az ilyen hibákat meg kell fognia.
Üdv:
Dw.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
nem volt kiírás utáni ellenőrzés, nem is tudom, hogy hpq/cciss vezérlő támogat-e ilyet, mindenesetre biztos roppant gyors lehet...
- A hozzászóláshoz be kell jelentkezni
Adaptec vezérlőknél van background consistency check, LSI Megaraid-nél és Dell PERC-nél patrol read-nek hívják. 3ware-nél autoverify. Persze performance impact-ja van mindegyiknek rendesen, ezért mindig van hozzá valami schedule.
Smartarray-nél egyenlőre nem találtam meg ezt a funkciót.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Csak tippelem, hogy valahol egy cache/buffer céljára szolgáló memória hibázik.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
> RAID5-öt használunk RAID1 helyett, mert az remélhetőleg mindig benyalja az adatok mellé a paritást is
A raid5 sem tesztel az inkonzisztenciára.
- A hozzászóláshoz be kell jelentkezni