IBM-u vinzu vea tuvastamine

[felch]

Hei, systeemi mehhaanikud!
Kuidas oleks kõige kavalam kindlaks teha vindi seisund? Tegemist on IBMi 30G rattaga ja temal jookseb üks server. On teine aeg-ajalt kõvasti puusse pannud aga ei tootja ega ka muud testid vigu ei näita.
Hüva, kahtlustasime masinat ennast aga nagu ei oleks - täna viskasin vindi(d) (peale järjekordset crashi) teise masinasse ja Fedora Core uuesti peale. Paari tunni pärast jälle...segmentation fault Süsteem jäi siiski üles!
Masinat nagu enam kahtlustada ei saa, jääb vint (2 tk, teine /home/ jaoks). Või on ikka veel mõni asi, millele tähelepanu pöörata?
Enne oli OS-iks Punamütsike, nüüd Fedora. Tundub,et crond taaskäivitus mõjutas kuidagi viga (kutsus uuesti esile) kuid kindel ei ole. Hetkel jookseb jälle kuid ajuti viskab segm. faulte.
Any clues?

[saformo]

1. mida teatab HDD S.M.A.R.T. (sellel targal on nüüd käivitamisel aeg endast märku anda)
2. kontrolliksin HDD jahutust
3. vaataksin http://www.computing.net/programming/wwwboard/5.html, mida arvatakse foorumites
4. kui vajalikud andmed käes, siis hävitaksin partitsiooni ja looksin uuesti, formaatimisel kasutaksin vigade avastajat

Kui seis jääb samaks, siis ilmselt lõpetaksin HDD maise eksistentsi ...

Igaks juhuks vaataksin üle veel ketta jumperid ja mida on selle kohta kirjas HDD kaanel. Ühele IBM üksikule HDD-le ei meeldinud kui jumper oli Masteris (veel vähem Slave), tahtis hoopis neljandat varianti, mis ei olnud ka Cable Select. Aga see variant on vähetõenäoline.

[digital]

Mõnikord võib ka olla jama distros endas, mitte rauas. Endal oli serveris jama mandrake 9.2'ga. Mandrake 9.1 jookseb ideaalselt aga 9.2 kõigi kaasa tulevate kernelitega (2.4, 2.4enterprise, 2.6) pangestub, masin on p4, 2,4G. Huvitav oli see, mõned proged lihtsalt ajasid kerneli mälujaotuse tsüklisse... 1G ram, 2G swap ja kui see otsas oli, siis tuli kernel panic ja hakati suvalisi protsesse killima... ja oligi maas. Üks proge oli näiteks rpm võtmega -q, siis oli veel mingi mandrake security teema ja isegi nii pisike ja lihtne adduser. Nädal aega sai jamatud ja viskas üle, tõmbasin 9.1 versiooni ja proovisin sellega - kõik töötas kenasti ja hetkel juba 2 kuud uptime. Mandrake poole sai vaadatud kunagi ammu seetõttu, et tal oli ainukesena vlan 802.1q tagging toetus kernelis, teises oleks pidand ise hakkama kernelit tegema, edaspidi juba harjumusest....

[digital]

Ahjaa, ketta kontrollimisest kaa... Pmst pead mingi utikaga lugema ketta smart-informatsiooni... Seal on kirjas, kui kaua ketas sektorit otsib ja kaua tööle läheb ja kui palju kasutatakse veakorrektsioone jne.
Linuxis on siuke utikas nagu smartctl, lihtsalt trüki kommand prompti smartctl -a /dev/hda vms ja hinda ketta füüsilist olukorda numbrites.

[felch]

Tähh kaasa mõtllemast!
Hetkel asi kuidagi stabiliseerus. Muidu nagu süsteem jookseb kuid näiteks üritades crond-le restarti teha (tahaks termomeetri skripti käivitada)sain vastuseks segm. fault.
Huvitaval kombel ei lase Fedora crond-d peatada - kas tõesti vaid reboot on lahendus? Punamütsike nii pircakas ei olnud...
Olen ka kuulnud et Fedora sarnaneb stabiilsuse poolest natuke ühe suure op-süsteemiga Ilmselt mul siis 2 muret - vale distro ja vale wintz. Ketas ise on 4 aastat vana Suure Sinise 30Gb sitaratas. Kuskilt lugesin et esimesed sellest seeriast olidki bugised. Kas võib tõele vastata?

[saformo]

Asi hakkab koomale tõmbuma.
Kopeeriksin kogu ketta sisu korras HDD-le. Kui seis jääb samaks, on viga OS-is.

[vtl]

Asi hakkab koomale tõmbuma.
Kopeeriksin kogu ketta sisu korras HDD-le. Kui seis jääb samaks, on viga OS-is.

ei tõmba ta midagi koomale :P

on masinaid, kus fedora1 toimib sama hästi, kui redhat 8 või 9. minu toshiba laptop on näiteks selline.
samas võib netist leida lugematul hulgal kaebamist erinevate anomaaliatega fedora all. küll ei anna installida, küll pangestub kõige müstilisemates kohtades...
mingi tegelane kurtis ee.arvutid.unux.linux.vestlus grupis hiljuti konkreetselt, et SMP kernel pangestub dual-xeon masinal kaks korda päevas ja selle kohta pidi ka bugzilla kirje olemas olema.

isiklik kogemus oli hiljuti ühe tuttuue masinaga: 2.6G cel, 256M ram, intel 865 chipset. esialgu installisin fedorat paar aastat vana 30G ibm vindi peale. installis ära, masin on tattaeglane. desktopi-rakenduste laadimisajad on kümnetes sekundites. nt. openoffice (ka korduv, cachest) laadimine ca 30 sekundit (normaalne oleks, kui see nii kiirel masinal *teistkordselt* ca 10-5-2 sek käivituks).
graafiline pakihaldus jooksis kinni. selgus, et fedora installi-cd (ka käsitsi) mountimine lihtsalt hangub...
vastavate protsesside tapmine ei aita, tahab rebooti.

kuna ma ei usaldanud ka toda ibm-i vinti, sai selle asemel masinasse pandud tutikas seavärav. sellele ei õnnestunud üldse fedorat installida. install lihtsalt hangub selle koha peal, kus peaks installiskript käima tõmmatama. (sama häda olen varem ka newsis kuulnud)

cd installimedia test arvab, et cd on ok. pange tähele, samas masinas eelmisele, ibm-i vindile installeerus. kirjutasin igaks juhuks uue cd, ikka sama jama. samad plaadid teise masinaga töötavad.

olukorra lahendas redhat 9 install, kõik toimis perfektselt.
masin on kiire ja sujuv.
(proovisin ka sama masinaga winxp installi. perfektne)

ütle veel, et "asi hakkab koomale tõmbama"

[vtl]

...Ketas ise on 4 aastat vana Suure Sinise 30Gb sitaratas. Kuskilt lugesin et esimesed sellest seeriast olidki bugised. Kas võib tõele vastata?

kuskil 3-4 aastat tagasi kui ibm deskstar gxp75-d turule tulid, hakkasid paari-kolme kuu pärast levima signaalid, et nimetatud vintsud kärvavad massiliselt. alguses hakkasid spetsiifiliselt klõpsima, kolksuma ja kriuksuma, ning siis surid lõplikult.
küll liikusid legendid, et tegu on "ühe kindla merekonteineriga, mis olevat maha kukkunud", siis leiti, et viga on "ungaris tehtud mitsubishi chipiga" vintides, philipiinidel ja malaisias tehtud ja ibm-i chipiga vindid pidid ok olema...
lõpptulemus oli see, et aasta-kahe jooksul koolesid enamus nendest ibm vintidest, olenemata, kus nad tehtud olid.

järgmine seeria oli minu mälu järgi gxp60. kõik müüjad kinnitasid, et "vot need on nüüd head". tutkit. läksid ka need muudkui garantiisse.

millaskis peale seda ilmusid turule gxp120-d. benchmarkide järgi oli tegu ühtede kiireimate vintidega tol hetkel.
asi läks aga kurjaks, kui storagereview.com avastas, et nendel vintidel on spetsifikatsioonis tehase poolt antud "maksimaalne töökoormus 350 tundi kuus", mis teeb ca 11 tundi päevas!

paljud tegelased esitasid suurele sinisele küsimuse, et kas seda vinti serverisse 24/7 tööle panna ei tohigi? vastused olid äärmiselt ebamäärased. et tohib küll, aga me soovitame serveri jaoks ikka teisi (scsi) vinte jne.
ametlikku seisukohta ibm-ilt ei tulnudki.
selle peale võttis storegereview gxp120-e oma recommended ketaste nimekirjast maha.

samal ajal asendus nimetatud 350h piirang vindi tehnilises spetsifikatsioonis soovitusliku lausega ning hiljem kadus sealt hoopis. mingil hetkel oli mul lausa kolm peaaegu ühesugust pdf-i nimetatud vindi spetsifikatsioonidega, mis erinesid teineteisest ainult tolle tööaja nõude poolest.

mõnda aega hiljem vastas üks ibm-i tehnikutest mitteametlikult storagereview küsimustele, kus ta küll otse ei kinnitanud probleeme, kuid andis mõista, et vintides kasutatav pixie dust tehnoloogia alles areneb ning ütles ka, et tulevastes vintides ilmselt sellist 350h tunni piirangut ei rakendata.
jutt oli pikk ja põiklev, kõike enam ei mäleta. nali on veel selles, et storagereview on intervjuu praeguseks maha võtnud.

nondest paljureklaamitud scsi serverivintidest veel: võib-olla mõni veel mäletab ca aastavanust kõlakat, kui tigma veebiserver otsad andis. muuhulgas oli mitu nädalat maas ilm.ee, jäädavalt kadus eesti päevalehe 90-te aastate arhiiv ja hulgaliselt muid väiksemaid ettevõtmisi.

lugu oli väidetavalt selline: raid5-s ütles üles üks ibm-i vint. kuna tegu ei olnud hotsvapitava kastiga, oli vindi vahetuseks vaja süsteemile korraks shutdown teha. poweroffi käigus kärvas aga ka teine vint ja oligi kogu raid kasutu.

osa eesti raadio elektroonset arhiivi hävines mingil ajal. arhiiv koostatud jällegi ibm-i ketastel.

rääkimata lugematu arv iseenda käe alt läbi käinud garantiilistest ibm-idest. ma ei tea tänaseks ühtegi ibm60/75/120 vinti, mis oleks tööle jäänud.

sama jutt muide fujitsu kohta. mingi partii 20Gb isendeid, mida siin paar aastat tagasi müüdi, pidas vastu täpselt aastase garantiiaja ja mõni nädal. nagu kellapomm oleks sees tiksunud. kui ühes õppeklassis hakkasid nädala jooksul ridamisi vindid lendama, siis peale 10-t otsustati kõikides masinates kettad välja vahetada. vahetamise käigus, kui teise vindi lisamiseks ja andmete ümberkopeerimiseks korraks vool maha võeti, lendasid ülejäänutest ka veel pooled :P

[felch]

Fuijtsu ketaste kohta üleks lausa s...rattad! Nende 10/20GB sarjas oli viga tootmises: kivid joodeti plaadile liiga agressiivse räbustiga mis hakkas mööda kiv jalgu klotci sisse imbuma ( kapillaarsus vist, ehh füüsikud?). Tulemus on see, et vaid loetud eksmplarid ( milledel räbustit kokku hoiti?) on senini elus. Õnneks sain enda töömasinas windist kuu enne garantii lõppu lahti!
Osadel Maxtoridel oli mingil hetkel firmware mis 1 aasta möödudes IGAL JUHUL toru ära pani. Ütle siis veel mis winti on mõtet osta!?
Senine seavärav töötab siiski (3*ptüi üle õla) juba 4-ndat aastat tõrgeteta. Nii Linuxi kui ka XP-ga. Viimane aeg back-uppida?

Teema juurde tagasi - mida asjatundjad ikkagi soovitaxid 24/7 serveri OS-ix Punamütsike - Mandrake -Debian või veel miskit (eeldades et ma s...ratta asemel windi hangin)?

[vtl]

leidsin mõned artiklid, õigemini jäänused:

http://www.storagereview.com/articles/2002...20AVVA07_1.html

"...A stumbling block of sorts appeared with the 75GXP. Although the drive continued to deliver first-rate size and speed, an unusually large number of users complained about reliability problems with the model. A similar though lesser situation arose with the 60GXP, though its unclear whether or not users unfairly attributed "mundane" problems that occur to all drives (and/or all users) to the 60GXP's lineage. SR does not hold an opinion one way or another on the matter; we simply point out what we've observed..."

kui sama threadi pidi paar lehte edasi minna, siis leiab veel sellise lõigu:

http://www.storagereview.com/articles/2002...20AVVA07_7.html

"...Addendum 3/5/2002: Readers called to attention IBM's recommendation of just 333 power-on hours per month in the drive's spec sheet. Since server drives usually must run 24 hours a day, Maxtor's DiamondMax Plus D740X remains ATA's best server disk. For more information, check out this headline..."

Addendum (samuti mitmeleheline ja põhjalik) on loomulikult kadunud, nagu ka ibm-i datasheet ja link foorumile.
teiste reviewde vanad lingid foorumile kusjuures töötavad.

[digital]

Endal oli ka see õnnetu Fujitsu ketas... paar kuud peale garantii lõppu läks asi müstiliseks... Nagu kui oli sama kontrolleri taga ka kirjutaja, siis ei detektitud ei kirjutajat ega fujitsut ära, muidu funkas kõik... veel paar nädalat ja enam üldse ei tundnud seda ketast ära... tööl pistsin teise arvutisse ja seal veel sai andmed üle kopeerida... seejärel oli täitsa laip...
Ja kui ta algul oli kirjutajaga ühe kaabli taga, siis veel toimus kirjutajaga ka mingi anomaalia... lihtsalt nüüd koguaeg ees punane led põleb... ükskõik mida teha... kui siis loeb, siis läheb roheline ka põlema ja asi muutub oranzhiks. Flashisin veel igaks juhuks ta uuesti, et äkki sai firmware kannataga aga see nagu töötab... müstika...

[felch]

Fujitsul läks 1 kivi füüsiliselt peeti, tema sees olev trackide info samuti. Kavalad vennad vene saitidelt aga leidsid lahenduse kuidas teiselt plaadilt võetud kiviga info siiski välja lugeda. Töökaaslane demonstreeris - tõepoolest sai laibalt kõik välja pinnitud.

[tahanteada]

Kõikidel HDD tootjatel on kodukatelt allatiritavad diagnostikaprogrammid. Siin "nutmise" asemel võix korra IBM-i kodukat külastada

[felch]

Nuta nii et maa märg aga diagnostika ei näita midagi. Anomaaliad jätkuvad. Kui juhtusid lugema, siis sellest juba kirjutasin. Proovin mõne kindlama vindiga.

[saformo]

Kui sama HDD ühe OS'iga jookseb kenasti, aga teisega mitte (ja esimesele OS-ile tagasi minnes jälle sama seis), siis peale raua võiks kahtlustada ka ühildumist.

Kas kõik on ikka 100%, nö AllFullCompatible. Standarditele vastavust mõtlen, peaks ju olema kui nii kirjas, aga kas tegelikult ka?

Hiljuti kirjutati ühest CPU-st, milles avastati viga ja mis seetõttu müüdi odavamalt maha, aga see on juba teine teema.