ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverLinux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Diszk failMa a napom jó részét eltöltöttem egy döglődő lemezzel. Nem adta meg magát teljesen a rohadék, hanem sunyi módon, random időközönként egy pillanatra megállt, majd elindult. A vezérlő ilyenkor - biztos ami biztos - reset-elt egyet. Ilyenkor a RAID-ben levő párja is megszomorodott ideiglenesen. Ez azt okozta, hogy 5-8 percenként az OS gyakorlatilag megfagyott, majd miután a vezérlő nyomott egy reset-et, akkor ment tovább, mintha mi sem történt volna. Az egészben az a szép, hogy az Insight Manager egy rohadt kukkot sem szólt az egészről. Szerinte minden szép és jó volt a rendszerben. Zöld volt minden indikátora. Nem hogy vöröset, de még sárgát sem jelzett. Mivel a logokban azért volt utalás a reset-re (lsi_sas - The driver detected a controller error on \Device\RaidPort0), odamentem a géphez és elkezdtem hallgatózni, hogy mi lehet. Így kiderült, hogy az egyik diszk szarakodik. Ezután már alaposabban megnézve látszott (nem az Insight Manager-ben, hanem a vezérlő gyártójának 3rd party programjában) hogy a vezérlőn túl sok a reset (Phy Reset Problem Count 1267902). De a RAID-re ez is azt írta mint az Insight Manager, hogy minden OK. Tipikusan olyan probléma, ami távolról nem állapítható meg 100% biztosan, csak sejteni lehet. Viszont fizikailag szemügyre véve azonnal látni (és főleg hallani), hogy mi a hiba. A rossz lemez eltávolítása után a controller reset problémák eltűntek. Az élet megy tovább, viszont
(PS: nincs valakinek elfekvőben egy ilyen diszkje eladó? :)
»
|
7r3yKeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 7% Összes szavazat: 567
Új felhasználók
InformációKövess minket!Partnerünk |
Ez nem jó ?
http://discountechnology.com/Seagate-ST3146855SS-SAS-Hard-Drive
1 hete ebből még kettő is volt , de úgy látszik másnál is kopnak.
Akár jó is lehet, köszi megnézem. Tudok szerezni 75 ezerért (nettó) itthon, de sajnálok rá ennyit. A vas hamarosan leváltásra kerül, így nem költenék rá ennyit, ha egy mód van rá.
--
trey @ gépház
Vagy alkudj az IBM diszkre !
http://hup.hu/node/109286
Elég viseltesnek látszik :)
Mindegy, a régi lemez leadásával azt beszámítják, így 70 ropi helyett 43 ezerért adnak egy másikat. Megrendeltem.
--
trey @ gépház
Úgy már egész baráti az ár. :)
lehet tenyleg van abban vlmi amikor rosszakat mondanak a hw raidekrol :]
Ez csak relativ, a sw RAID nyugosebb tud lenni. Disk halal ellen semmi nem ved.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal"Disk halal ellen semmi nem ved"
De !
Egy jól szervezett RAID , és a tisztességes backup.
Hogy lehet rosszul szervezni egy raidet?
Raid1 + spare szerintem boven jo szokott lenni (3 kulon gyartotol a legjobb, nalunk legalabb 2 mindig mas gyarto, pl. 2 * seagate+ 1* wd felallas tipikus)
"Raid1 + spare szerintem boven jo szokott lenni"
Akár jó is lehetne , de persze a spare diszk halálára akkor szokott fény derülni amikor valamelyik üzemi is elesik.:)
Jogos a ket pont.
Tenyleg, erre ki kellene talalni valamit asszem....:)
Nem lehet a spare disk motorját leállítani?
...bár ettől még tönkremehet...
Talan egy extended smart tesztet erdemes hetente lefuttatni, de igazabol egy full resync lenne jo, mert ha arra kerul a sor, hogy hasznalni kell, pont ez tortenik majd.
3 diskbol RAID1. Gyakorlatilag a hot spare-t is berakod dolgozni. Igy kihullhat egy, de tovabbra is redundans a csere + tomb ujraepites alatt.
Igen, ez a jó megoldás !
Itt 2 diszk is megállhat , az adatok túlélik.
Ráadásul egyszerű a mentésről gondoskodni , mert leállítasz egy diszket , kiveszed és az a backup.
Azon kívül a sok szálú olvasást is szépen gyorsítja.
Nincs többlet költség a RAID1 2 diszk + 1 spare konfigurációval szemben.
Konkretan LSI/3ware/Areca kontrollerek mindegyiket lattam mar furcsan mukodni, mdadm -et pl meg nem.
Areca kulonosen nagy kedvencem.
Én láttam már IBM ServeRAID-et is, de hát ami gép és ami elromolhat, az el is romlik. Ami itt cinkes volt, hogy sok 100 ezernyi reset-et a HP management szoftver nem vett észre. OK, hogy ment a lemez, de prefailure-ben már régen ki kellett volna löknie.
--
trey @ gépház
ez valami 200-as sorozatú cciss?
LSI SAS 3000
--
trey @ gépház
Neked legalább túlélte a rendszer... Négy Kingston SSD-ből négyet hajított ki valamelyik nap a raid-vezérlő egy gépben (és ez nem az első alkalom, szinte biztos, hogy a kiírt adatmennyiségtől függ, hogy meddig bírja az adott kombináció, mert egy reboot után hibátlannak látja a diszkeket, és működik is a cucc), úgyhogy lehetett újraépíteni az adatbázist rajta...
Szerencsére holnap négy Intel SSD megy a helyükre.
Milyen vezérlő ez ?
Az lshw ezt mondja róla:
product: LSI MegaSAS 9260
vendor: LSI Logic / Symbios Logic
Nincs TRIM támogatás , és garbage collector.
Van viszont SSD Guard , ami a fene tudja mit takar , de szép hangzatos.
http://75.126.99.220/showthread.php?t=1502231
Lehet ,hogy érdemes volna olyan SSD-vel próbálkozni aminek a vezérlője maga intézi ezt a feladatot.
Pl:Toshiba T6UG1XBG, JMicron JMF618
Az "SSD guard" nekem egyszerű hot spare-nek tűnik...
Én ebben elég konzervatív vagyok, SSD-t egyelőre csak a saját laptopomban mertem megkockáztatni. Arra egyelőre beválni látszik.
--
trey @ gépház
Lehet konzervatívnak lenni, viszont jelen esetben négy SSD-vel költséghatékonyan lehetett gyors storage-ot varázsolni az adott DB alá. Nem egy gépről van szó, nem kis terhelésről, és prímán muzsikálnak az Intel SSD-k.
Melyik Intel SSD típus ?
510-es sorozat (120GB-os darabok).
Ezeken a Marvell 9174 vezérlő van.
Ezeknek kell a TRIM !
Mindenesetre nem nagyon örülnék, ha több alkalommal full crash lenne. Nekem 12 év alatt egyszer nem kellett disaster recovery-t csinálnom. Nem is szeretném ha ez változna.
--
trey @ gépház