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
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
Csak tippelek, de szerintem a resync befejeződött. Ezért nincs is mind a kettő offline állapotban, csak az old. Az old _szerintem_ detacholható.
Nagyon érdekelne, mi lett a végeredmény!
"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"
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
A ZFS jó értem ?
Hello. Nem egészen értem a kérdést, de gondolom, arra gondoltál, hogy a zfs tömb áll e helyre ettől, normális online állapotba. Szóval, elméletileg igen. Üdv Wolfwood
Csak egy "fricska volt" semmi egyéb :) nem kell mögötte értelmet keresni :)
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:
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
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:
Ebbol a felallasbol a fenti ddrescue + disk csere + zfs scrub lepeseket megismetelve:
A ZFS RAID-Z1 vissza tudja allitani az adatokat es a paritast ugy, hogy nem lesz Permanent error.
Hogy rakod vissza a jó diskeket a rosszak helyett a ddrescue után? Én úgy tudom, hogy a ZFS WWN-nel dolgozik, ami nyilván más lesz az új diszk esetében, tehát azt mindenképpen új diszkként fogja felismerni, hiába vannak rajta ugyanazok az adatok.
Miert lenne baj, hogy uj diskkent ismeri fel?
A 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:
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"
Ha új diskként ismeri fel, akkor nem foglalkozik a rajta lévő adatokkal, hanem mindent visszaszinkronizál rá.
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
Köszi, hogy megírtad mi lett a vége! Örömteli, hogy nem veszett el a pool.
Általában sajna lemarad ez a rész a kérdezős posztok végéről.
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
zpool status?
es mi a pontos parancs?
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
Helyesen: 'zpool detach', pls figyelj ra.
En meg mindig errorokat latok ebben a pool-ban. Mit mutat zpool clear utan?
Scrub végigfutott?
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).
Hello. A zpool clear parancs is szépen lefutott a pool on és egyenlőre mindent kinullázott. Akkor így most már elméletileg jónak kellene lennie a diszk eltávolításnak is? Köszönöm. Üdv Wolfwood