Pedig ez történt. A szerver szünetmnetessel táplált, a memória ECC-s, de egyébként ezt követően (mint ahogyan azt a beüzemelésnél is) teljes hardver tesztet kapott, és ahogyan a telepítéskor úgy az ellenőrzésnél is hiba nélkül teljesített. Újraindítva sem volt, pusztán annyi történt, hogy a szokásos évenkénti teljes SMART offline teszt erejéig lecsatoltam a filerendszert, leállítottam a RAID tömböt. és elindítottam az offline SMART tesztet mind a 4 vinyón de egyszerre csak egyet. Mindezt azért mert lett felfüggesztett hibás szektor amit csak offline tesztnél tudott javítani a rendszer. És miután a hiba sikeresen javítva lett az offline teszt során, egy újabb, már hibamentesen lefuttatott offline teszt után amikor a tömböt újraindítottam, már gyanús volt, hogy nulláról kezdi a szinkronizálást, majd jött a meglepi a felcsatolhatatlan filerendszer, a lemez (RAID5) fizikai méretét meghaladó filerendszer méret miatt.
Én arra tippelek, hogy a reallokálás nem spare területre történt, hanem az egyik lemez fiizkai mérete lett valóban kisebb (vagy nem is történt reallokálás csak megjelölte hibásnak, lehet már nem is volt olvasható a tartalma), emiatt már a RAID mérete sem stimmelt és ez zavarhatott be.
Akárhogy is a 2.7TB-os tömbből boldogan feláldozok 2-300MB-ot, hogy ez ne ismétlődhessen meg. Ettől függetlenül amit írtam a superblockokról meg a RAID konfigurációjáról, lemezbeálltások kimentéséről, továbbra is fenntartom. Nekem nagyon jól jöttek a helyreállítás során, mert bizony az fsck és a resize sem tudott elindulni amíg kézzel nem adtam meg egy valid superblock helyét. Tulajdonképpen ez mentette meg az "életemet", hogy ez az adat megvolt. Ennek nyilván a sérült filerendszer volt az oka. Ezek kimentése kb. 2 perces elfoglaltság, és pár száz byte adatról van szó, viszont éltetet menthetnek.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]