Zfs pool diszk csere probléma

Fórumok

Diszk csere után a replacing alatt ott maradt a régi diszknek a "linkje" és a folyamat hibára futott végül, ahol egy darab hibás fájl található. Miként lehetne javítani a degradált tömböt? Jelenleg egy elég nagy tömbről beszélünk, amiben nincsenek snapshotok és csak a fontos dolgokról van mentés, de jó lenne, ha nem vesznének el az adatok egy malőr miatt. A google ben a zpool scrub pool és a zpool clear pool parancsot javasolják, de még nem adtam ki. Valaki meg tudna esetleg erősíteni ebben, hogy erre ez a gyógyír? Köszönöm.

root@stg1:/root# zpool status -v
  pool: pool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: resilvered 5.05T in 65h26m with 1 errors on Fri Jan  1 03:52:46 2021
config:

        NAME             STATE     READ WRITE CKSUM
        pool             DEGRADED     1     0     0
          raidz1-0       DEGRADED     1     0     0
            sda          ONLINE       0     0     0
            sdb          ONLINE       0     0     0
            replacing-2  OFFLINE      0     0     0
              old        OFFLINE      0     0     0
              sdc        ONLINE       0     0     0
            sdd          ONLINE       0     0     0
            sde          ONLINE       0     0     0
            sdf          ONLINE       0     0     0
            sdg          ONLINE       0     0     0
            sdh          ONLINE       0     0     0
            sdi          ONLINE       1     0     0
        spares
          sdj            AVAIL

errors: Permanent errors have been detected in the following files:

        /mnt/storage/valami.gz
    

root@stg1:/root# zpool history
2020-12-29.09:41:24 zpool offline pool 4012839354214699166
2020-12-29.10:26:20 zpool replace -o ashift=9 pool 4012839354214699166 /dev/sdc

root@stg1:/root# zdb
pool:
    version: 5000
    name: 'pool'
    state: 0
    txg: 28696671
    pool_guid: 14089924342026554290
    errata: 0
    hostid: 8323328
    hostname: 'stg1'
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 14089924342026554290
        create_txg: 4
        children[0]:
            type: 'raidz'
            id: 0
            guid: 6755275009510535222
            nparity: 1
            metaslab_array: 36
            metaslab_shift: 38
            ashift: 9
            asize: 54010443202560
            is_log: 0
            create_txg: 4
            children[0]:
                type: 'disk'
                id: 0
                guid: 11064214669236398238
                path: '/dev/sda1'
                whole_disk: 1
                create_txg: 4
            children[1]:
                type: 'disk'
                id: 1
                guid: 13507590225516951596
                path: '/dev/sdb1'
                whole_disk: 1
                create_txg: 4
            children[2]:
                type: 'replacing'
                id: 2
                guid: 15733673123223733177
                whole_disk: 0
                create_txg: 4
                children[0]:
                    type: 'disk'
                    id: 0
                    guid: 4012839354214699166
                    path: '/dev/sdc1/old'
                    whole_disk: 1
                    DTL: 246
                    create_txg: 4
                    offline: 1
                children[1]:
                    type: 'disk'
                    id: 1
                    guid: 16033800647744749539
                    path: '/dev/sdc1'
                    whole_disk: 1
                    DTL: 247
                    create_txg: 4
                    resilver_txg: 28696668
            children[3]:
                type: 'disk'
                id: 3
                guid: 7751324156916513465
                path: '/dev/sdd1'
                whole_disk: 1
                create_txg: 4
            children[4]:
                type: 'disk'
                id: 4
                guid: 11197819723486236712
                path: '/dev/sde1'
                whole_disk: 1
                create_txg: 4
            children[5]:
                type: 'disk'
                id: 5
                guid: 342993940855163304
                path: '/dev/sdf1'
                whole_disk: 1
                create_txg: 4
            children[6]:
                type: 'disk'
                id: 6
                guid: 13737018497333603841
                path: '/dev/sdg1'
                whole_disk: 1
                create_txg: 4
            children[7]:
                type: 'disk'
                id: 7
                guid: 2343349341947863028
                path: '/dev/sdh1'
                whole_disk: 1
                create_txg: 4
            children[8]:
                type: 'disk'
                id: 8
                guid: 5036193290447877584
                path: '/dev/sdi1'
                whole_disk: 1
                create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data

root@stg1:/root# uname -a
Linux stg1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

Hozzászólások

Szerkesztve: 2021. 01. 04., h – 17:28

NEkem úgy tűnik 1-nél több diszked hibás. dmesg/syslog mit mutatott a replace alatt?

BTW ha van spare diszked a raidz helyett érdemes raidz2-t használni inkább spare nélkül.

Hello. Itt jelenleg egy hibás diszk lett cseréve az /dev/sdc alatt, ahol a régi helyére került be az új. A korábbi ott a /dev/sdc1/old ként található meg. Tudom, hogy egy raidz2 lenne az optimálisabb választás, de sajnos egyelőre ebben a környezetben nem kivitelezhető. A tesztek alapján a diszk csere egy 18.04 es Ubuntu alatt jól működött, itt viszont sajnos ez a kimenet állt elő. Hogyan lehetne ezt az állapotot normalizálni. Köszönöm a segítséget. Üdv Wolfwood

De hát ott az sdj spare-ként. Miért nem arra replace-eltétek mielőtt cseréltetek? Na mindegy, eső után köpönyeg.

A gond az, mint ahogy írtam, hogy az sdi is hibásnak tűnik. Annyit megpróbálhatsz, hogy kiadod ezt a parancsot:

zpool clear pool sdj

Hátha csak valami nem permanens olvasási hiba volt.

Szerintem is az a helyzet, hogy a diszk csere közben egy másik lemezen is talált hibát a ZFS, ami a már kiesett lemez miatti redundancia hiányban már nem javítható, ergo permanens hiba.
Biztosan van syslog-ban vagy dmesg-ben olyan bejegyzés, hogy unrecoverable read error egy másik lemezen (nem a cserélten).

A hiba mellett lévő linken ponosan leírja, mi történt és mik a lehetőségeid: Van olyan fájl, ami redundáns példány hiányában nem állítható már helyre. Ha a hiba az állomány adatrészében van, akkor az állomány törölhető (és mentésből kell visszaállítani, a hiba megszűnik), ha a metaadatban van a hiba, akkor viszont az állomány ugyan mozgatható a pool-on belül (de nem olvasható), és csak a pool megsemisítésével és újra létrehozásával lehet tőle (és a hibajelzéstől) megszabadulni.

Nézd a jó oldalát: ha egy HW RAID vezérlőn esik ki egy RAID5 kötetből egy diszk, és egy másik read error-t jelent ezalatt, akkor azonnal elveszett az összes adat, nincs mit tenni. Itt még van lehetőséged minden más, nem sérült adatot lemásolni a pool törlése és újraépítése előtt.

Ezért nem szabad RAID5-öt használni. Soha.
Plusz minden fontos, amire az ember azt mondja, "jó lenne, ha nem veszne el". Ezeket mind menteni kell. Csak azt nem kell menteni, amin el sem gondolkodsz, hogy mi van, ha elveszik.

Hello. Köszönöm az információkat. Akkor ezek szerint nincs nagy veszteni valóm, meg kell próbálni a zpool clear parancsot azon a diszken, ahol a badsectoros probléma jelentkezik. A samartctl szerint 16 badsector van rajta, elméletileg evvel még nem szabadna földbe állnia a tömbnek, így egy próbát megér. Alap esetben nem használnék raid 5 öt, de amikor egy megörökölt rendszerről beszélünk, akkor sajnos nem nagyon lehet mit csinálni. A jelenlegi állapotban a replacing-2 szekció pontosan mit jelent, amiben benne van az old is és mind a kettő offline állapotban van? Ha kiadom a clear parancsot a zpool automatikus szinkronizálása automatikusan el fog-e indulni? Köszönöm. Üdv Wolfwood

Nagyon érdekelne, mi lett a végeredmény!

A kellően fejlett technológia, megkülönböztethetetlen a varázslattól.
Arthur C. Clark

Kapcsolja vissza a mikrofont!
Winston Churcill

Hello. Jelenleg fut rajta a scrub általi ellenőrzés, ami nagyjából még 2-3 napig el fog tartani. A clearral sikerült egyenlőre leresetelni az sdi diszket, ha szerencsénk van és holnap estére nem jelentkezik ismét ez a hiba, akkor a deatach al kikerül belőle az old lemez és remélem, hogy eltűnik majd vele együtt a replication-2 is. Azt követően pedig, ha rendbe jön a tömb, akkor a spare re lesz kicserélve a másik problémás diszk is. Amennyiben pedig nem hoz ez a forgatókönyv eredményt, akkor le kell menteni a rajta lévő temérdek adatot, készíteni egy új tömböt a másik rossz diszkkel egyszerre kicserélve, majd visszamásolni mindent. Viszont ha a gigabites hálót koppon ki is hajtjuk, majdnem 6 nap átmásolni mindent illetve vissza. Így első körben ezt szeretném elkerülni, ha lehetséges. Köszönöm. Üdv Wolfwood

Szerkesztve: 2021. 01. 06., sze – 06:54

Most mar valoszinuleg mindegy ebben a konkret esetben, ezert csak elmeleti lehetosegkent emlitem meg hogy hogyan lett volna esely megmenteni az adatokat.

(Mondjuk azert ennyi diskkel en sem hasznalnek RAID-Z1-t soha)

 

Az elmeleti felallas: A kommersz diskeken hetente futtatott zfs scrub eszreveszi hogy az egyik disk rossz (tehat write/read timeout miatt a zfs kidobja). Nevezzuk ezt a disket BADDISK01-nek

A bad sector altalaban nem az egesz disket eszi meg, hanem csak egy reszet:

BADDISK01:
OOOOOOOBBBBBOOOOOOOOOOOOOOOO

O - OK
B - BAD SECTOR

Mivel a ZFS 2^(ashift) meretu allocation unitokkal dolgozik, es ezeket checksumolja -- ezert ha pl. (GNU) ddrescue-val atmasolod az adatokat egy jo diskre (GOODDISK01), ezert ahol a BADDISK01 bad sectoros volt, ott eselyes hogy a GOODDISK01 checksum hibakat fog eredmenyezni, de ezt paritasbol helyre tudja hozni zfs scrub soran

GOODDISK01:
OOOOOOORRRRROOOOOOOOOOOOOOOO

O - OK
R - RECOVERABLE CHECKSUM ERROR

Ha a zfs scrub soran kiderul, hogy van meg egy disk ami bad sectoros (BADDISK02), akkor azert kell imadkozni hogy ne ugyanott legyenek a bad sectorok:

GOODDISK01:
OOOOOOORRRRROOOOOOOOOOOOOOOO

BADDISK02:
OBBBOOOOOOOOOOOOOOOOOOOOOOOO

O - OK
B - BAD SECTOR
R - RECOVERABLE CHECKSUM ERROR

Ebbol a felallasbol a fenti ddrescue + disk csere + zfs scrub lepeseket megismetelve:

GOODDISK01:
OOOOOOORRRRROOOOOOOOOOOOOOOO

GOODDISK02:
ORRROOOOOOOOOOOOOOOOOOOOOOOO

O - OK
B - BAD SECTOR
R - RECOVERABLE CHECKSUM ERROR

A ZFS RAID-Z1 vissza tudja allitani az adatokat es a paritast ugy, hogy nem lesz Permanent error.

Miert lenne baj, hogy uj diskkent ismeri fel? 

zfs scrub nem fog irni rajuk csak olvasni azokon a teruleteken ahol megvannak az eredeti jo adatok, es csak az R blockokat fogja irni a cserelt lemezeken.

A lenyeg, hogy ne legyen atfedes -- RAID-Z1 eseten egy teruleten max 1 disk lehet checksum problemas -- ha ennel tobb, akkor abbol lesz Permanent error.

A te konkret esetedben valoszinuleg ez van:

EMPTYDISK01:
RRRRRRRRRRRRRRRRRRRRRRRRRRRR


BADDISK02:
OBBBOOOOOOOOOOOOOOOOOOOOOOOO

O - OK
B - BAD SECTOR
R - RECOVERABLE CHECKSUM ERROR

Mivel az ures lemezterulet is R-nek minosul -> igy jott elo a Permanent error

Az, hogy ebbol meg vissza tudsz-e jonni, az nem biztos -- ezert is a hozzaszolasomban egy elmeleti lehetoseget irtam le, hogy "hogyan lehetett volna"

Azt nem tudom hogy a mai "modern legújabb csiligány" ZFS hogyan mukodik, a fent leirt eljarast sikeresen vegigvittem FreeBSD 10-en n evvel ezelott tobbszor is.

Lehet hogy az eltelt idokozben elrontottak a resilver kodot es azota tenyleg alig jobb egy ZFS mint a sima RAID5.

 

Oszinten szolva, nem lennek meglepve ha igazad lenne.

Hello. A történet véget ért, a lényeg, hogy a scrub sikeresen lefutott az sdi clear után és csak az az egy darab fájl sérült meg, a tömb is vissza állt online ba. Ezt követően a replacing-2 ből eltávolítva deatach al az old diszket szépen eltűnt. Majd a másik hibás diszket is a replace el lecserélve a spare re szépen lefutott, ott is megjelent egy spare-8 hasonlóan a replacing-2 höz. Abból is ugyan úgy ki kellett venni deatach al a rossz diszket a sikeres resilvering után és az is eltűnt. Szóval a végén a tömb újra vissza tért a normális állapotába és annyi fejlemény történt menet közben a többi diszket is átvizsgálva, hogy van még egy disc, amit cserélni kell. De annál már a procedúra ugyan az, maga a zfs nem egy rossz dolog, elég jó adatvédelmet nyújtott ezek után. Viszont tanulság, ha sok diszk van, maradjon a raidz2, amire már a kezdetekkor érdemes gondolni. Üdv Wolfwood

Hello. Egy olyan újabb probléma merült fel diszk lecsatoláskor, hogy miután kiadtam a zpool detach pool gid parancsot a cannot detach gid: no valid replicas hibaüzenet jött elő és nem lehet eltávolítani a pool ból. Magában a syslogban a parancs kiadásával egyidejűleg nem találok erre egyértelmű hibaüzenetet. Pedig a pool ban a spare ben jelenleg a diszk online állapotban van. Van esetleg valakinek ötlete, hogy mi okozhatja ezt a jelenséget vagy hogy hogyan lehetne deatachelni a diszket a tömbből? Köszönöm. Üdv Wolfwood
 

Hello. A zpoolban van jelenleg egy spareben két diszk, amiből el akarom távolítani a hibásat, de a zpool deatach pool sdh ra visszadobja a detach sdh: no valid replicas hibaüzenetet. Van esetleg ötlet, hogy ez mitől lehet? Köszönöm. Üdv Wolfwood

        NAME         STATE     READ WRITE CKSUM
        pool         ONLINE       1     0     2
          raidz1-0   ONLINE       1     0     4
            sda      ONLINE       0     0     0
            sdb      ONLINE       0     0     0
            sdc      ONLINE       0     0     0
            sdd      ONLINE       0     0     0
            sde      ONLINE       0     0     0
            sdf      ONLINE       0     0     0
            sdg      ONLINE       0     0     0
            spare-7  ONLINE       0     0     0
              sdh      ONLINE       0     0     0
              sdi    ONLINE       0     0     0
            sdj    ONLINE       0     0     0
        spares
          sdi        INUSE     currently in use

Hello. A scrub korábban már lefutott, van egy fájl hiba a pool ban, de azt nem lehet eltávolítani, avval sajnos egy darabig még együtt kell élni. A pontos parancsok az alábbi példa szerint futottak le. Köszönöm. Üdv Wolfwood
 

1. zpool replace pool -o ashift=9 /dev/sdh /dev/sdi

(Ez sikeresen lefutott.)

2. zpool detach pool /dev/sdh
cannot detach /dev/sdh: no valid replicas

(Ez már nem futott le és a korábbi hibával tért vissza. A diszk nem volt offline módba állítva, elképzelhető, hogy ez a baja?!)

3. zpool clear pool sdh

(Majd sikeresen lefutott a disc clear, de csak magán a disc en és nem az egész pool on. Ezt követően a detach ismét sikertelen volt a korábbi hibaüzenettel.)

Ezert futtasd a 'zpool clear' parancsot (magaban, parameterek nelkul).