ZFS guru kerestetik

Naplózó filerendszerek (journaling)

Sziasztok!

Egy ismerősöm szív egy FreeNAS által létrehozott ZFS-sel:

"Freenas 8.03-on 2x2TB, (mirror). Az egyik disken megjelent egy "Pending 3 sectors" hiba. Itt volt a baj, hogy nem foglalkoztam vele elég gyorsan-volt már ilyen, akkor egy-két hónappal később kicseréltem a hibás disket, jó lett. Hát, most nem cseréltem ki és egyszercsak beütött a krach: a másik (tehát addig jó) disk agyhalott lett egyik pillanatról a másikra (próbáltam azóta, csak kattog bekapcsoláskor, aztán le is állítja magát).

Nos tehát van egy olyan tükröm, amin van 3x4096B szektorhiba. Csináltam róla dd_rescueval másolatot, azzal kísérletezgetek, de nem jutottam eredményre, nem tudom importálni a zpool import-tal (-fFX -szel sem tud importálni).
Ubuntu 12.04 server + telepített zfsutils-szal játszom. Leírás szerint teljes a támogatása zfs-re. Próbáltam FreeBSD-vel is, azzal sem tudok importálni.

Nem értek a zfs-hez, szóval lehet, hogy hülyeséget írok: nem cél a pool helyreállítása. 1.4TB-nyi adat van rajta, de kb. 8-900GB-nyi adat elég kritikus (grafikus a szerencsétlen user), azt kéne valahogy megmenteni...."

Tehát olyan embert keresünk Budapesten, aki - fizetés ellenében - tudna segíteni az adatok (ZFS partíció) helyreállításában.
Vagy ötlet is jöhet, hogy mit kellene még kipróbálni.

Köszi,
spymorass

  • 5813 megtekintés

( elod v | 2014. 05. 13., k – 22:56 )

Ez szerintem elég nagy fail a zfs-nek.

Illett volna a pending szektort magától javítania. Illetve az sem világos hogy miért borul ki 3 hibás szektor miatt...

Kíváncsi vagyok mit mondanak a hozzáértők.

Nem vagyok hozzáértő - csak a félreértések elkerülése végett.

Az miért a ZFS hibája, hogy az előre jelzett várható hardver hiba ellenére nem készítettek biztonsági mentést, nem cserélték a rossz hardvert, majd a másik meghajtó halálakor elvesztek az adatok? Én még sem szoftveres, sem hardveres RAID megoldásról nem hallottam, ahol az összesen 2 db merevlemezből mind a kettő meghibásodhat, és az adatok elérhetőek maradnak...
Egy rendes RAID (legyen az SW vagy HW) már 1 szektor hibánál is szól. Az átlag HW RAID vezérlő azonnal ki is köpi a HDD-t ilyenkor. A pending szector hibát a HDD vezérlője kezeli, nem az OS/FS relokálja a rajta lévő adatot.

Plusz fekete pont (az üzemeltetőnek), hogy a ZFS leírás egy pár figyelmeztetéssel kezdődik, és "a nem importálható ZFS pool-ról adatot menteni nem lehet, nincsenek helyreállító eszközök ehhez az FS-hez" eléggé a lista elején van, hogy észrevegye, aki belenéz.

A különböző RAID megoldások az üzemszünetek számát és időigényét hivatottak csökkenteni, elsősorban nem az adatok örökkévalóságnak őrzésére lettek kitalálva. A való világban kell valamilyen RAID az élő adatok alá, és egy elszeparált mentés valami tartósabb eszközre (ez akár egy másik RAID eszköz is lehet, amin nincs terhelés - ha a költséghatékonyság a cél). Manapság pl. 5 USD körül van havonta a korlátlan tárhelyes CrashPlan, harmadik védelmi vonalnak simán alkalmazható, ha tényleg fontosak az adatok.

Mi van olyan esetben, ha a ZFS-t futtató gép tápegysége romlik el és magával viszi a két HDD-t. Ez kb. olyan eset (hardver hiba). Arról is az FS tehet?

Elnézést a kirohanásért, de egy ilyen hibaleírás utáni ilyen reakcióra muszáj voltam írni.

csak a zfs hibaturesere reagalva:

azert en eleg problemasnak erzem azt, hogy tetszoleges 3 szektor (mint fentebb 3x4096 byte) kiesese falhoz vag egy filerendszert annyira, hogy egy darab hasznos byte-ot sem tudok lementeni belole. az a filerendszer ami a fentieket nem teljesiti, szerintem nem hasznalhato kb semmire. itt most nem arrol beszelek, hogy kell mentes vagy nem (termeszetesen kell).
nem lehetne ezt kivedeni? ennyire problemas lenne a fontos reszekrol (inode-tabla akarmi ami zfs-nel van) masolato(ka)t tartani ilyen esetre? ertem, hogy ez csokkent(het)i a performanciat, de ha nem lehet valasztani legalabb, hogy szeretnek-e ilyen plusz vedelmet, az elegge elitelendo.
van meg hova fejlodnie a zfs-nek vagy egyszeruen "this is by design"?

zfs ugye a reklám szerint azt is bírja ha belerondítanak, nemhogy 3 szektort de egy csomót.
én itt inkább attól tartok, hogy mindkét vinyó ténylegesen megdöglött, és bármi elpusztult volna rajta nem csak a zfs.

amúgy itt több hiba is van:

- minek zfs produktív környezetbe annak aki nem ért hozzá? (én se értek hozzá még)
- ha már fontos/kritikus akkor mi a túróért nincs backup?

--
Gábriel Ákos
http://i-logic.hu

Az OP-ben lévő leírás alapján a következő történt:

- első HDD-n volt pár szektor hiba, ezzel nem foglalkoztak
- eltelt két hónap, senki sem tudja, közben az első HDD-vel mi lett - valószínű sokkal több hiba lett rajta, így a második HDD-ről dolgozott a ZFS
- második HDD megállt mint a szög, ekkor elmúlt a pool elérése, kettőből kettő egység kiesett alóla

Szóval ezt semmilyen FS nem viseli jól. A ZFS resilver folyamata a checksum-ok miatt nem túl gyors. Ráadásul minél több az adat annál tovább tart. Ezért is írják sokan, hogy a TB-os HDD-k korában már nem engedhető meg, hogy csak 1 eszköz eshessen ki (cikkek sokasága szól a RAID5 haláláról pl.), mert a csere eszköz felépítése közben simán befigyelhet egy nem javítható hiba a még jónak tűnő forráson (pláne nem-vállalati kaliberű HDD-kkel), és akkor oda az egész.

A várhatóan meghibásodó szektor miatti áthelyezést nyilván megcsinálta a HDD. Viszont utána az OP-ben írtak szerint nem néztek rá többet a megállásig. De ha elkezdtek gyűlni a rossz szektorok (merthogy nyilván elkezdtek), akkor azzal nem tehet semmit a szoftver, cserélni kell az eszközt. Ha egy HW RAID5-ből egy egység várható hibáját jelzi a felügyelet, akkor úgy hagyod, hogy jó az még? És felháborodsz, mikor utóbb kiderül, hogy az az egység meghibásodott, majd egy másik is, és akkor hívnak, mikor a két kiesett HDD miatt megállt a kötet? Ez az eset szerintem teljesen független attól, hogy milyen FS volt a HDD-ken.

Egyébként ZFS-en megadhatod, hogy egy-egy file-ról mennyi másolat készüljön. Ha van több másolat (itt a másolat nem tükrözés másik HDD-re, hanem még egy példány valahol a dataset-en), akkor az egyik sérülése nem okoz gondot előveszi onnan, ahol jó - szektorhibák ellen, fontos adatokhoz. Ezt a különböző RAID jellegű megoldásain felül lehet "bekapcsolni". Tehát lehet 3 HDD-s tükröd a pool-ban (2 HDD hibát tűr), azon egy olyan dataset-tel, amiben minden file 3 példányban tárolódik (nyilván így a harmada lesz a hasznos kapacitás az adott dataset-re). Ez nyilván overkill, de elég sokféle hardver hiba esetén megvéd. De ez beállítás kérdése, a ZFS sem tudja kitalálni, hogy az adott adat mennyire fontos, milyen szinten kell védeni...

A ZFS-nek egy "baja" van (ami így is marad by design), hogy ha szétesik a pool, mert már nincs elégséges forrás az adatok beolvasásához, akkor nincs hozzá recovery eszköz, ami a több különböző módon sérült HDD-ről összerakja az eredeti pool-t működőképesre. De megfelelő tervezéssel/konfigurálással 100%-ban elkerülhető az ilyen szituáció.

Már megbocsáss, de pont ez a lényege a RAID-nak hogy pending szektor meg ne történjen.
Amint pending szektorba fut kutya kötelessége azt reallokálni a TLER lejárta után. ZFS esetén dettó. Akkor maradhat pending ha nincs honnan kiolvasni az információt és az már régen rossz.

Szándékosan voltam provokatív, nem értem hogy ez miért nem így történik. Pont ez a helyzet linux softraid1 esetén is. Csücsül a pending szektoron és várja hogy történjen valami.

A neten mindenhol úgy írják, hogy a pending sector hibákat a HDD kezeli, ha tudja, áthelyezi az adatot az ilyen célra fenntartott területre.
A vezérlő (legyen az SW vagy HW) csak arról kap információt, hogy a kért adat hibátlanul olvasható vagy sem, ez alapján dönt a HDD használhatóságáról.

Nem tudja kezeli, ezt a intelligens (RAID) host-nak kell(ene) újraírnia, azonnal. Desktop esetében nyilvánvaló hogy ez miért nem történik meg, itt viszont elég necces.
wiki

Kíváncsiságból ráengedtem egy dd-t (olvasást) egy 3 Pending-et mutató WD800BB-re. Hiba nélkül végigolvasta. Az biztos hogy érdekesen kezeli a "problémát".

Elnézést, nem szeretném a végtelenségig ragozni, de az általad linkelt Wiki oldal is ezt írja:

Current pending sector count: Count of "unstable" sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it's written.[33] However some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the "Reallocation Event Count" (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.

Ahogyan más, interneten fellelhető források szerint is a HDD-nek kell kezelni az ilyen jellegű szektor szintű hibákat. Szerintem nem az OS/FS párosnak kell megoldani, hogy a HDD-n nyilván tartsa a gyanús szektorokat, és migrálja róla az adatokat máshová, ha sokáig fennáll ez az állapot (merthogy honnan tudná az OS, hogy a kiszemelt célterület nem egy másik problémás szektor pl.).

( sibike | 2014. 05. 14., sze – 11:22 )

Meg kellene nézni Solaris alatt, ott a legvalószínűbb, hogy sikerül feléleszteni, ill javítani, ha szükséges.

( balintdavid | 2014. 05. 14., sze – 12:19 )

BSD levlistán nagyobb eséllyel kapsz értelmes választ, mint itt
De ha ennyire fontosak az adatok, akkor vidd be a Kürthöz.

( uid_228 | 2014. 05. 14., sze – 14:24 )

Újabb FreeNAS-t próbáltál, hátha tudja importálni?

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

( Athes v | 2014. 05. 15., cs – 13:27 )

Küldtem mailt. Itt csak azt sikerült a kisközönségnek kitalálni, hogy miértnehsználjproduktívkörnyezetbenZFStfőleghanemisérteszhozzá.