Vettem, most már 4 db WD2000FYYZ (yellow) használt diszket. Volt ami <10.000 órát futott 10 "Power cycle" -al.
Mindegyikkel ugyanazt a tesztet végeztem el:
- smart lekérdezés és short test
- törlés, újra particionálás és formázás (egy elsődleges ext4 -es partíció)
- badblock -vw /dev/sdx1
Három hiba nélkül átment, a negyedik viszont folyton lereked:
2022.12.10.
tovis@emb111:~$ sudo badblocks -vw /dev/sdb1
Checking for bad blocks in read-write mode
From block 0 to 1953513559
Testing with pattern 0xaa: ^C
Interrupted at block 905255808
2022.12.11.
Első látásra mindig ugyanott. Ha csak úgy egyszerűen be mount -olom simán írtam rá néhány gigás fájlt.
A rendszer naplóban nem találok semmit!
Azt forgatom, hogy visszaküldöm és cseréljék ki. De mit mondjak, mi lehet a baj ha nem tudom detektálni a hibát?
Mi az ördög lehet ez?
Próbálkozzak dd -vel jó nagyot írni? Szerintem a badblock sem csinál mást.
Hozzászólások
megfuttatnám az fsck.ext4 is, hátha mond valamit
Futtass rajta sima olvasás tesztet: badblocks -s /dev/sdx1
Most épp a házi szerveremről tömöm, érdekes módon működik, megy.
Nem értem :(
* Én egy indián vagyok. Minden indián hazudik.
Elmagyarázom.
A 905255808 blokk 1k-val éppen 863G.
Közeledik - 602G - most már kivárom :)
Ezzel az aritmetikával sosem voltam jóban. Én 512 byte -ra vélek emlékezni.
17:42 952G semmi hiba.
* Én egy indián vagyok. Minden indián hazudik.
Segíthet a man badblocks. ;)
Hullik a hajam :(
49 óra alatt a 2T -ból 45% -ig jutott - nincs hiba.
A man ból legalább a progresst előtudtam hívni :)
* Én egy indián vagyok. Minden indián hazudik.
49 óra alatt 10db 2T-s diszket végig kéne tudnod tesztelni. Milyen módon és gépben nézed ezt?
Nálam a diszkek újra használata előtt kapnak egy dd-vel végignullázást, és utána egy badblocks -sv -t. Ami nagyon rossz, az már eleve lassan megy, és a dd alatt kihalnak. Amik kevésbé gyászosak, azok a badblocksnál dobnak hibát. Mindkét esetben sajnos ehulladék a sorsuk.
Másolok.
Már >350G és semmi hiba.
Nagyon furcsa.
* Én egy indián vagyok. Minden indián hazudik.
Ha a 905255808 blokknál szakad meg, akkor ott van (az első) hiba.
Nézd meg a kernel logot (dmesg) mit ír.
Diszket menet közben nem tesztelünk - még ha nincs rajta rendszer akkor sem!
Töltsd le a HDAT2 programot és futtasd DOS boot lemezről! (Természetesen usb stick vagy pxe segítségével.) A gyorsabb vizsgálat érdekében a 905255808-10000 blokknál (szektornál) indítsd a hibakeresést!
Mit tudsz tesztelni egy diszken:
Mik ezek
A csilió low lever format program felejtős, mert azok a 2. szerinti szektorok adattartalmát írják felül. Ehhez a funkcióhoz ezeknek a szektoroknak az idexét is újra kellene írni, de erre interfészen keresztül nincs lehetőség.
Ha az előbbinél jobb a helyzet (tehát nem sérült az 1. szerinti index), akkor a megtalált hibás szektor(ok) újraírásával, vagy a megfelelő interfész szintű paraccsal lehet kényszeríteni a hibás szektor kihelyettesítését.
Ha nincs sok hibás szektor, akkor az előbbivel meg is javítottad a diszket!
Ha valaki a HDSentinel-t javasolja, annak se hidd el! ;)
Második verzió: Megvizsgálhatod mi van, ha a kezdő blokk > 905255808. Ha nincs több hiba, vagy csak az első hiba környékén szaporodnak, akkor particionáláskor kihagyhatod a hibás részt.
Harmdik verzió:Elolvashatod ugyanezt, mert már vót:https://hup.hu/node/172065
No igen, ismétlés a tudás anyja.
Viszont, itt épp az a furcsaság, hogy sem a napló sem a smart nem mutat semmi érdekeset - ilyen még nem volt velem.
A smart valóban nem ad elégséges információt egy hibás diszkről. Viszont ha van naplózott szektor hiba vagy relokáció az látszik, az életkor és a poweron/off ciklus szintén beszédes (az ilyen diszkek arra voltak kitalálva, hogy nem kapcsolgatják ki, akkor > 150.000 óra az MTBF).
A HDSentinel is leginkább csak arra jó, hogy lásd a diszk hőmérsékletét. Nálam most nem túl jó 56°C -nak mutatja - egy mobil rackben tesztelem ahol nem elégséges a hűtés (az emlegetett házi szerveremben minden diszk < 40°C).
Mindenesetre megy a másolás, amennyire látom töretlen 75MB/sec (mc).
Utána jöhet egy fsck és egy badblocks olvasós teszt.
* Én egy indián vagyok. Minden indián hazudik.
Nekem speciel segitett a hdsentinel - de nem kell elhinned.. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Inkább elhiszem. Létezik az a tudásszint, amihez képest még a téves információ is előrelépést jelenthet. :-D
Tudod, én műszaki szakember vagyok. A műszaki dolgok tényekkel, adatokkal leírhatók, ezért nem képezik hitvita tárgyát.
Egy diszk interfészen keresztül vizsgálható, eltekintve a külső körülményektől. Az utóbbiak pl. a vizuális megfigyelés (ráesett-e az üllő, vagy szétverték-e kalapáccsal?), vagy a beépítés és a rezonancia. (Bár a utóbbit mérheti a diszk is.)
Tehát egy elektromechanikus szerkezet egészen addig vizsgálható, amíg az üzemi paraméterei a megengedett határértékeken belül tartózkodnak. Sajnos az IDE interfész megalkotása óta az egyszerű felhasználó nem fér hozzá a diszk alapvető paramétereihez, csak a firmware által emulált felületet látja. De sebaj, ott van a SMART, ami lényegesen jobb lehetőségeket biztosít, mint a kártyavetés. :-D Erről fellelhetsz néhány vizsgálatot és tanulmányt is, amit nem kell elhinned: A SMART alapján kb. pontosan a semmit lehet megjósolni. Szintén léteznek statisztikus mennyiségű eszközön végzett élettartam mérések (pl. google), amik viszont jól korrelálnak a gépészeti alapismeretekkel. A diszk általában statisztikai modellel vizsgálható, valószínűségeket adnak meg az adalapokon, de az élettartamot megbízhatóan megjósolni nem lehet. A diszk állapotának megítéleséhez a hiba trendet érdemes figyelembe venni. (IBM)
A fentiekhez párosul az a tény is, hogy az operációs rendszerek szinte kivétel nélkül nem kezelik a diszkek meghibásodását. (Kivétel pl. az AIX, de ehhez a fícsörhöz az IBM saját firmware-t tett a diszkekbe.*)
Ehhez képest a kedvenc szoftvered: Igen nagy biztonsággal jósol és meghatározza a diszk fitnessz faktorát százalékban. Ezzel elhiteti azt is, hogy "kézben tartod a dolgokat".
Tipikus eset, amikor 1 db szektor meghibásodása esetén már csak 99%-os a diszk. (Bármit is jelentsen a 99%.) Matematikailag ez egy 20GB kapacitású diszknél ez 0,00000256% hibát jelent. A hibás szektor helyettesítésére több tartalék szektor áll rendelkezése minden track-en, meg még máshol is. A hibás szektorok kihelyettesítése normál üzemmód ezeknél a diszkeknél, csak nincs rá automatikus módszer. Így aztán tökölhetsz kézzel. Avagy sajnos ehulladék a sorsuk, pedig a diszk cseréje után sem lesz lényegesen kisebb a meghibásodás valószínüsége. Ez az amitől a szervizesek a hajukat tépik, a hdsentinelre alapozott garanciális csere. Pedig ilyenkor elég a hibás szektort reallokációra kényszeríteni.
Megtörtént eset, amikor sokkal rosszabb volt a diszk, mert. hdsentinel barátunk tán 90%-ot sem adott a diszknek. Történetesen a szerkezet válaszolt az identify parancsra, egyébként nem pörgött fel, meg se nyekkent. Azaz egyetlen bitnyi információt se tudtál írni-olvasni. Hát azóta "nem hiszek igazán" a hdsentinel képességeiben. :-D
* Abban az esetben, amikor az operációs rendszer kezeli a meghibásodást, mégpedig AIX "idegen" diszkkel, kb. így néz ki egy napló:
Ha nem tudsz ilyet mutatni linux vagy Windows alatt, akkor rájössz mivel foglalkozik ez a topic. (is)
En nem vagyok szakembere a temanak. Eppen ezert amikor volt egy bad sector bejegyzes az egyik diskemen, akkor csinaltam egy felulet ellenorzest, aminek hatasara a bad sector athelyezesre kerult - onnantol ez mar nem jelent meg ujra, es a disk azota is jol szuperal. Tudom, hulye vagyok hozza... :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Bár nekem sincs akadémiai diszk-tudor doktorátusom, csak szeretem tudni mit csinálok.
Egyszerű esetben - némi smart vizsgálat után - elég akár dd-vel végigírni a diszket. Ekkor nagy a valószínűsége, hogy a pending sector-ok eltűnnek, mert csak azért pendingelnek, mert még nem akart rájuk írni senki. (Aztán néha meg nem tűnnek el.)
Sokkal gyorsabb, ha a smart hibalista alapján teszi ezt egy erre szakosodott program. Ezért javaslom a HDAT2-t, mert ezt is tudja. A "most powerful" vizsgálata pedig read-write-read módban dolgozik, ami egyúttal "helyben" frissíti is a diszket.
Vannak sokkal bonyolultabb esetek is. Pl.
A smart hőmérsékletnapló alapján 0 ℃ környékén kapcsolták be a számítógépet, amikor 1 db hiba jelentkezett (véletlenül a Windows pagefile elején, azaz "nem indult a gép"). Nem a szektor sérült, hanem az indexe, ami üzem közben soha nem íródik, legfeljebb kihelyettesítéskor, de akkor is értelmes értékre. És azt hogy mondod meg, hogy a nemtudomhanyadik szektort helyezze át? Némi küzdelemmel és több programmal csak sikerült kiütni a helyéről.
Volt egyszer 3db 500GB-os diszkem, amiből 2 ugyanolyan volt, de egy kis példányszámban gyártott al-típus szerepelt rajta. No, ezekben kísérleti szervó programnak örvendhettem. Az utolsó 12-16GB kizárásával hosszabb ideig használtam őket. A kisérleti firmware a halkabb seek elérése céljából készült, ezért a diszk végében abszolút véletlenszerű lett az elérési idő (akár 100x-os), miközben méhraj szerű hangokat lehetett hallani. ;) A részletes bevizsgálás (MHDD) megmutatta, hogy még folyamatosan olvasva is össze-vissza változnak a seek idők, illetve néha el sem sem találja a kért címet.
Szerintem azért érdemes kicsit utánanézni a dolgoknak, mert kis türelemmel a lehetetlennek tűnő javítást is el lehet végezni, vagy idő hiányában kizárni a bonyolultabb eseteket. Kivétel a topicnyitó, hiszen már másodszor görcsöl hasonló problémával, de még mindig nem hallgat rám. :(
Az van, hogy diszkbe nem fogunk belelátni, és pont a technológia összetettsége tudd megfoghatatlan problémákat generálni*. Onnantól kezdve, hogy 49 óra alatt néhány 100GB-t haladt a diszkteszt, elég nagy a gond, vagy nem normális blokkmérettel nyomod a dd-nek például.
Egy dd bs=1M -t ha rá tudsz nyomni, és nem áll meg, majd utána hibátlan a badblocks -sv, akkor egészen jó vagy, de ha irreálisan hosszú, akkor felejtős a diszk, mert valami már ott halódik. Egy mai diszk 160-180MB/sec körül kezdi a dd-t, és kb. 100MB/sec körülre esik le a vége felé a sebesség.
* Természetesen ezek a problémák laborelemzéssek valamire visszavezethetőek, de badblocks, meg hallgassuk a hangját, és házi körülmények között marad a "megfoghatatlan", és a kukázás. Azzal sem vagyunk előbbre, ha 453,4 mérnökórával kiderül, hogy elengedett egy forrasztás, mert valami IC már a végét járja és néha túlmelegedett, vagy esetleg a tányéron kijött egy gyártási hiba, és azért, mert a diszkfej már erősebb krafttal írta, hibás IC miatt, mint amúgy kéne...
Igazad van és a hozzáállásod is jó.
DE.
A dd bizony csak egy userspace szoftver. Ha ismert a mögé kötött eszköz, akkor annak a paramétereit illik figyeleme venni. Ilen pl. a /dev/rmt, ahol tudnod kell, hogy milyen blokkolást szeretnél / tud az eszköz. A dd jónagyblokkal paraméterezve csak addig jó, amig tudod mit csinálsz.
Pontosan ezért érdemes a diszk tesztelésre kihegyezett szoftvert használni, mert az ismerni fogja az eszköz és az interfész maximális blokkméretét, és tudja elemezni az írási parancs állapotjelentését. Ugyanakkor képes használni a diszk teljes parancskészletét, amelynek egy része ki van maszkolva az userspace felé. A badblocks - elegendő jogosultsággal - megkerülheti a kernelt, de sokkal tisztább és szárazabb érzés, ha közvtelenül meg tudod szólítani a diszket. Ezért nem szerencsés (védett) operációs rendszer alól diszket tesztelni. Bár futtatam Windows + qemu alól DOS boot diszkről tesztet, ami előtt engedélyezni kellett a diszk kontroller portokhoz az userspace -> privilegizált hozzáférést. Hasonló akadály lehet, ha boot után a diszk security freeze lock állapotba kerül, amit pl. a tápfeszültség elvételével lehet megszüntetni.
A futásidő minimuma a teljes diszkre a smart-ból kiolvasható, mint az extended selftest vagy a format unit várható ideje. A komplex teszt legalább 3-4x ennyi ideig futhat.
És igen, tudni kell, hogy mikor érdemes feladni! A másik véglet a hdsentinel 1 szektoros hibájából eredő csere. Először azt hittem, hogy a cserélt diszket a szervizes sitty-sutty megjavítja és eladja, de tényleg ennyire sem ért hozzá. )
Nagyon túlgondolod, mert bármelyik diszk az kopóalkatrész. A gyári sw-k csak végső esetben hasznosak, ha adatot akarsz menteni, vagy nagyon új a diszked (1-1,5 éven belüli). Ha a diszk haldoklik, az kiderül egy dd+badblock kombónál, és ha ez a helyzet, akkor ehulladék. Hiába fogod szupertesztelni a gyári csodával, az a fizikai hibán nem fog segíteni, vagy csak időszakosan. A hibák amiket írsz, azok rendkívül ritkák.
A diszk hiba vagy úgy derül ki, hogy kidobta a raid vezérlő, akkor gari függvényében ezt cserélik (bár van gyártó aki még jön a húzza ki dugja be mantrával...), vagy cseréled magad, illetve ha az OS-ed eldobja a diszket. Mindkét esetben nem a szél hordta össze a problémát. :) Ezt megelőzendő a dd+badblock kombóval szoktam a használt diszkjeinket tesztelni, mielőtt újra éles szerverbe kerülnek. Itt a 30-40 ezer óra feletti diszkeknél már többször fordult elő, hogy végük lett, és a smartot megnézve azért nem alaptalanul, és messze nem egy darab badblock miatt, vagy 1%-nyi hdsentinel parától.
Levezethető közgazdaságilag is, hogy egy 20-30-40e-50e forintos alkatrészre hány órádat (villanyszámlástul) teszed bele. Ezt majd mindenki eldönti, hogy hobbizgat-e diszk élesztéssel.
Azt a két extrém példa csak érdekesség volt. Természetesen egyik sem szerver környezetben történt.
"Minap" elfogyott a munkaterület egy olyan szerveren, amelyen 120+ cég backup rendszere megy. (Nem én üzemeltetem.) Elküldték a diszk rendszer kialakítását, amihez csak egy észrevételem volt: Először az egyik raid1 hiányzó felét kellene pótolni - még a diszkcsere előtt. ;)
Itt - "közgazdaságilag" - egy csomó szerződés buktája a tét, ha a raid1 másik lába is elbotlik.
A jelenség oka (a spóroláson kívül) a linux, amely az első hibára kidobja a diszket. Mint a hdsentinel. ;) Pedig ezek szerver kategóriájú diszkek. (>>50eFt)
Az Intel specifikációja szerint a szerver/kommersz diszk - bár így fejből talán pontatlan lehetek:
Szóval, pontosan milyen módon döntöd el, hogy a "diszk haldoklik"? Egy dd+badblock kombó semmit sem mond, viszont egy szerver kategóriás diszk kidobása egyetlen (vagy száz) hibás szektor után mindenképpen pénzkidobás. Nem véletlenül említettem az AIX-et, mint olyan operációs rendszert, amely képes kezelni még a diszkeket is. ;)
A kockázatot úgy lehet csökkenteni, ha a tervezett élettartam végén mindig cseréled a diszkeket. Addig meg - a katasztrofális meghibásodás kivételével - egy normális diszk nem kezdhet haldoklani. Ha a hibák trendje nem utal az elhasználódási szakaszra, akkor van létjogosultsága az erre hivatott szoftverrel történő tesztelésnek és javításnak. (Alternatív megoldás: 3 üzemeltetőből 2 kirúgva és a helyükre entry level POWER server. Hidd el, hamar megtérül!)
Otthoni diszk bevizsgálás, ha 2 napig megy a teszt:180Ft villanyszámla és 2 óra munka. Mivel nettó >20eFt-os, 5 év garis diszkeket használok, nem rossz az arány. (A topicnyitó huptársunk esetében tök felesleges a költségeket kiszámítani. :-D)
Ha kidobta a RAID vezérlő, akkor vége. Azt újra ki fogja dobni. Ilyenkor azért szoktam egy nullázást rájuk nyomni, hogy mégse csak úgy menjenek az ehulladékba (bár a RAID5/6/10 esetén 1db diszkhez soksikert kivánok bárkinek), és nem egyhibás szektor van, vagy már el sem indul a diszk, esetleg már jön a kattogás. Jellemzően egy enterspájz diszk valahol 50-60k óra felett adja meg magát, de van szerintem 90k+ órás diszk is üzemben még, bár szerintem az épp leállítás alatti gépek egyikében. A soksok kihalt diszk közül talán egy olyan volt, amit még tesztelős diszknek tudok használni, de már messze nem prod ready, hogy trendin mondjam.
Linux esetén hasonló a tapasztalat, de nézni kell a dmesg-et, hogy mi történik. Sima desktopnál a kábelhiba jelleg, pl. hibás csatlakoztatás/kirázódás
A közgáz dolog, csak a kivett diszkre vonatkozott, ne keverjed. Ha cserélni kell, akkor cserélik, és kész. Ahol prodban megy valami úgy, hogy nem tűnik fel egy diszk hiba, vagy a féllábas raid, hát az szomorú, lehet ott nem is lehet alkalmazni mindenféle logikát. :)
Biznisz felhasználásnál ha sikerült 5 év garit venni a gépre, akkor nem kérdés, hogy nincs igazán dolgunk a kidobott diszkkel, azon kívül, hogy kapjuk a cserét. Ha gariidőn túl vagyunk, akkor meg jó eséllyel annyit futott a diszk, hogy nem lepődünk meg, ha cserélni kell, és nem okozhat problémát a csere beszerzése. Azzal sportolni, hogy akkor a 300-1800GB 10k-15k SAS diszk most akkor picit halt meg, és még rávesszük a raid vezérlőt, hogy szeresse, majd X idő múlbva újra kidobja, az elég hazárdjáték, hátha egy másik diszket visz magával rebuild közben.
Ha már SSD, akkor egyszer volt egy érdekes SSD halál (kettő datacenter SSD halál közül az egyik, a mindkettő gariidőn belül, a másikat cseréltettem), amit a hdparm reset funkciójával sikerült valahogy megoldani. Ez annyira reset volt, hogy még a futásideje is nullára került. Ott akkor ez az SSD cserélve lett, már valahol máshol üzemel, még nem volt gond. Guglival annyit találtam, hogy "néha előfordulhat" (köszi), hogy backplane áramellátási issuenál így páff beáll a cucc. Azon a diszkhelyen azóta se volt semmi, sőt abban a szerverben sem volt, pedig mostanában még utazott is Bp remek útjain a masina.
Egyébként onnan indult a topik, hogy egy WD otthoni diszk dögledezni látszik. :)
Nem szerettem a valódi RAID megoldásokat. Egyszerű esetben (AIX) csak mirror-t használtam, ami +1 vagy +2 tükröt jelentett és azt kezeli a rendszer. A későbbiekben ún. hot spare is volt az os-hez. A tartalék install alatt felpörög, hogy szinkronban maradjon, majd visszamegy pihenni. Baleset esetén a hibás diszk leáll, a tartalék felpörög és szinkronizálódik. Volt egy gépünk, ami kb. 16 év után selejteztek. A néhány eredeti diszk mellett voltak frissebbek is... Nagy általánosságban, ebben az időszakban csak 2-3 elromlott diszket láttam, ebből egy gyári hibás. (30 szever és átlagosan 2..14 diszk/szerver.)
Egyébként onnan indult a topik ... Ez meg a hup, valamint nekünk meg valamivel csak szórakoztatni kell magunkat, ha a kérdező nem oszt meg elegendő információt ÉS nem fogadja meg az okos tanácsokat. Kisvártatva jön az újabb device, amihez harmadszor is le fogom írni ugyanazokat.
"Ha kidobta a RAID vezérlő, akkor vége. Azt újra ki fogja dobni. " - vagy nem. Intel szerver alaplap, rajta Intel raid vezérlő, ráakasztva négy darab nem Intel, de nem is gagyi SSD, RAID10-ben. Kontroller egyszer csak kidobott egy SSD-t, majd rövid időn belül a másikat, a harmadikat és a negyediket is. Gép kikapcsol, majd vissza, vezérlőre ránéz, hogy ugyan már, mit mond az ssd-k kapcsán... A tömböt újra összerakva 100%-os állapotot írt mind a négy ssd-re, a Linux bebootolt, egy fsck után gyakorlatilag megvolt minden. Aztán x idő (kiírt adatmennyiség?) után ismét elkezdte a hülyeségét, ismét kikapcs/bekapcs, és ismét simán megette a diszkeket a kontroller...
Ezek a "mind sz@r, dobd ki" olgok úgy három hetente előjöttek, így néhány alkalom után minden második héten kapott kikapcsolós reboot-ot a gép, és köszönte szépen, eztán nem volt baja a vezérlőnek az ssd-kkel, nem dobálta ki azokat a tömbből...
Ott igen komoly fw issue van, ha ilyen dobálást csinál. Mondjuk Intel-Intel szerverrel évek óta nem találkoztam, de lehet nem véletlenül. :)
Egyébként ez pontosan milyen hardware raid megoldás?
Régen volt, már nem nagyon emlékszem rá - valami ronda gui-s BIOS-ban kellett tapicskolni... És igen, fw issue volt az ok: a vezérlő és az adott ssd tipus "nem szerették egymást". Vuduka ásta bele magát jobban, sajnos őt már nem lehet megkérdezni róla... :-/
Nem tudtam felulirni, mert volt rajta cucc, de a hdsentinel felulet frissitese kb ugyanazt csinalhatja.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Sőt! Szintén ATA parancskészletet használ!
Tehát egyforma a kettő. :-D
Legfeljebb a DOS edition tudná, de az semmit nem tud. ;) OS alól diszket cseszegetni nem szerencsés dolog. Kicsit feljebb azt is leírtam, hogy miért.
Ha jól megfigyeled, három különböző dolog van odaírva. A különböző pontosan azt jelenti, hogy nem egyforma. ;)
Most en ezen biztosan nem fogok veled osszeveszni. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Dehogy akarok veszekedni.
Inkább az a karikatúra jut eszembe, amikor az éppen leszálló repülőgép műszerfalának közepén ott csücsül a Windows BSOD. ;) Pedig ez a tréfásan megfogalmazott igazság (Mindent arra használj, amire való!) annyira nem tréfa, hogy még az USA villamos hálózata is összeomlott egy Windows frissítés kihagyása miatt. Nem vették komolyan a viccet.
A S.M.A.R.T. nem IBM fejlesztés?
Ezt elolvasva nem, de ott volt a közelben. ;)
Ott írják, hogy az IBM először hasonlót SCSI-2 diszkeknél alkalmazott szerverben, míg amivel a hétköznapokban találkozunk azok IDE -> (S)ATA diszkek. Látszólag tökmindegy, de a legalább 20x drágább tecnológiák mögött hátha rejtőzki valami más a logón kívül. ;) Nem csak az az scsi-re, hanem a szerver - kommersz diszkek közti különbségekre gondolok.
197 Current_Pending_Sector is jó a smart szerint? A badblocks-t nagyobb blokkmérettel próbálnám (4k, 64k).
Próbálj meg smartctl -t long segítségével kierőszakolni rajta egy öntesztet. Hátha úgy ír valami hasfájást az -a kapcsolóval lekérdezett logban. Esetleg a gyártó külön bootolós tesztszoftverét is rá lehet ereszteni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Köszönöm a sok jó tanácsot és emlékeztetést.
A téma kezdetét elindító diszk semmilyen hibát nem mutat. Csurig nyomtam adattal, logikai szinten (fsck) OK, fizikailag semmilyen hibát nem dob a gép. Felmerült valakiben hogy a gép esetleg nem OK - három ugyanilyen diszket vizsgáltam pont így - nem mondom a badblock írással 1,5 napig futott rajtuk).
A diszk semmilyen más "furcsaságot" nem jelez, kivéve hogy badblock -al lassú.
Nem tudok mást dönteni, minthogy ez a diszk NEM kerül raid1 -be sem. Jó lesz menteni vagy amolyan digitális firkapapír lesz belőle. (A raid1 -et amúgy is úgy szoktam előkészíteni, hogy kettő be a gépbe, egy a szekrénybe "hideg tartalék" és egy backup, vagyis egy megbízható felálláshoz 4 diszk kell szerintem).
* Én egy indián vagyok. Minden indián hazudik.