ZFS recovery

ZFS Fan Club

Van (volt :-/ ) egy 4 disk-es ZFS RaidZ2 pool-om Ubuntu 22.04 LTS alatt, ami átmeneti disk elérési hibák (táp anomália) miatt kompromittálódott, nem importálható. Mit lehet vele kezdeni?

A gép (HP Microserver G8) kapott egy ideiglenes új tápot, a disk-ek így hibátlanul mennek, I/O hibák, fizikai bad sector-ok nincsenek.

- 'zpool import' felderíti, ráadásul hibátlan, online-nak mutatja a pool-t

- 'zpool import pool' azonnal elszáll disk I/O hibával, de nem közli, melyik disk-el van baja

- 'zpool import -fF pool' 8-10 órányi tekerés után száll el disk I/O hibával, de szintén nem közli, melyik disk-el van baja

A RaidZ2-nek elvileg a 4-ből 2 disk-ről is fel kellene állnia, de ha csak 1-et is kiveszek, azonnal disk hiányra panaszkodik és szintén nem importálható.

 

Milyen további lehetőségek, tool-ok vannak, hogy legalább részlegesen visszanyerhető legyen a pool-on tárolt adat. (Játszós home NAS ~3TB-nyi kacattal, amit ugyan el tudok engedni, ha reménytelen, de azért volt közte ez-az, amit szívesen visszanyernék - na meg, ugye a kihívás. Backup nyilván nincs :-) )

Régen elég komolyan belemásztam a ZFS témába, de ~5 éve kiszálltam ebből a vonalból, ezért sajnos nem csak hogy ennyi lemaradásom van, de még az akkori tudásom is erősen megkopott, így elkél a részletes segítség.

( micsa v | 2024. 11. 25., h – 10:56 )

zpool import -Ffm, végsőként pedig zpool import -FfmX ?

( _Franko_ v | 2024. 11. 25., h – 11:09 )

Hajj, sebeket tépsz fel... :D

Az a baj, hogy a ZFS olyan, mint a négykerékmeghajtás: arra jó, hogy a világ végén ragadj be, amerre más senki nem jár.

Nekem olyan rémlik, hogy a corrupted zfs.cache is tud szopást okozni, illetve ha megváltozik a device id, akkor lehet valahogy importálni közvetlenül megadva a dev nevét is.

https://iotguru.cloud

Mondjuk, van egy cache SSD is a képben, ami amúgy múltkor meghalt, de anélkül elindult a pool. Kapott másik cache SSD-t, azzal is ment már és az is stabilan ott van most neki - de megfordult a fejemben, hogy azt egyszerűen kivegyem, hátha, de ezt még nem próbáltam.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( sibike | 2024. 11. 25., h – 11:43 )

- 'zpool import pool' azonnal elszáll disk I/O hibával, de nem közli, melyik disk-el van baja

Es közben a dmesg-ben nem latszik semmi???

> google szerint nincs (2-3 TB WD Green/Red)

Ahogy Vasla_ írta, a WD EFAX (Red) gyanús, és elsőre ezt nem közölte a cég, bár később elismerte.  Ha mégis SMR van, az okozhat ilyen problémát.  Elvileg a ZFS tükrözés jó vele, de a ZRAID már problémás.  Nem szekvenciálisan replikál.  Az SMR diszk gyorsan kis CMR-területre írja az adatot, majd magától rendezgeti át SMR-sávokra, ami lassú.  Ez abból is látszódhat, hogy írások után egy darabig aktív az eszköz, amikor a buszon már nem kap adatot.  A replikáció viszont olyan tartós írási terhelést ró rá, amit nem bír követni, ilyenkor jöhet sector not found, vagy talán egyéb IO-hiba.  A sok órás próbálkozás után hibázás bennem pont ezt a gyanút ébreszti.

2TB-os SMR diszkekre RAIDZ1-et már tettem nagyobb rekordmérettel, ez alajpán: https://www.truenas.com/community/threads/update-wd-red-smr-drive-compa… - azért ilyen helyzetre különösen kell a mentés. Te látod, mennyire fontos adat van rajta, lehet, hogy jó lenne most másolaton kísérletezni, ha nagyon fontos, akkor két másolat is jó lenne, bár az szerencsés, hogy hardverhiba nem látszik.

A ZFS beépített integritás-öngyógyítás funkcióját valami blogon láttam már, hogy ritka ramaty állapotot is életben tartott.

Hát, az is lehet, hogy csak türelem kell hozzá.

A cache SSD-t kivenném, és talán a zpool cache-t is kikapcsolnám.

https://www.zfshandbook.com/docs/advanced-zfs/data-integrity-and-self-h… - Nekem úgy tűnik, hogy csak olvas (végigellenőriz mindent), és ha valahol javítani kell, csak ott javít.  Van ettől eltérő hivatkozásod?

Amúgy az SMR írási korlátról kösz az infót, erre még nem figyeltem.

Jó fogás sajnos.  A linkelt Servethehome oldalon írja, hogy az SSD-kre ez írási terhelés, ezzel szemben:

In contrast, the WD ratings are actually total data transferred and WD combines writes and reads in that figure.

Szóval mégsem jó ötlet smrból várat építeni.

Az összes WD Pro CMR, pl ha megnézed a datasheet-et innen.
A WD Plus az SMR - ebben majdnem biztos vagyok, aztán lehet ott volt a keveredés hogy 6TB -ig SMR, utána CMR.
Az 550TB/y terhelés ugyanúgy érvényes a WD Gold és az Ultrastar-ra, de Seagate Exos is ugyanúgy 550TB/y, és ez a három már enterprise kategória - bármit is jelentsen az manapság.
Mondjuk nem értem hogyan lehet ilyen terhelési adatok mellett Hadoop vagy Ceph clustert rátolni ezekre a diszkekre.
 

Minden bizonnyal rossz, illetve inkább hibás értelmezés.

HC550 datasheetjéből: "Projected values. Final MTBF and AFR
specifications will be based on a sample
population and are estimated by statistical
measurements and acceleration algorithms
under typical operating conditions,
workload 220TB/year and temperature
40C. Derating of MTBF and AFR will occur
above these parameters, up to 550TB writes
per year and 60°C ambient (65°C device
temp). MTBF and AFR ratings do not predict
an individual drive’s reliability and do not
constitute a warranty."

Ez alapján ez a workload dolog write vonatkozású, mig a datascrub az read.

Bocs, EFAX-ra nem kerestem rá, de az enyém EFRX (ez még valami régi RED, akkor még sem Pro, sem Plus nem volt). Illetve ~5 éve ment ez is stabilan, tehát nem gondolnék ilyen konstrukciór-/típusproblémára.

Az utolsó tippet köszi, arra megyek tovább.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Ha még kérdéses, hogy hogy lehet megnézni:

lsblk -D

Ha a DISC-MAX 0, akkor biztos nem működik a TRIM (tehát CMR, vagy nem támogatott).  USB-s SMR tárakon jellemzően nem támogatott a TRIM, de SATA esetében azért ez elég megbízhatóan működik.

Másik:

hdparm -I | grep -v trim

---------------

Gondolkozom, hogy trimmelés segítene-e.  Kockázatát is látom, és nem próbáltam még.  És nem tudom, hogy a poolod jelen állapotában engedi-e.

Ha megpróbálnád, csak --wait paraméterrel, remélem, úgy nem árasztja el a diszk command queue-ját (valahol írták, hogy anélkül biztos), illetve lehet, hogy a --rate is segítene.

( Atekka | 2024. 11. 27., sze – 14:32 )

zdb parancs mit mondd rá?
Ha csak readonly akarod behúzni? zpool import -o readonly=on "poolnév"

( cstamas | 2024. 11. 28., cs – 12:25 )

(Akik katasztófaturizmus miatt vannak itt azokat hagyd figyelmen kívül.)

Menj el a grml.org oldalra.
Ott van egy livecd, azt töltsd le és bootold be (talán usbról a legegyszerűbb).
Adj neki hálózatot, installálj zfsutils és zfs-dkms csomagot, ez géptől függően eltart egy ideig (a te gépednél 10-20 perc talán)
modprobe zfs
zpool import $poolname

Ezzel kiderül, hogy az OS-nek van baja vagy tényleg a tömb.

( bzt | 2024. 11. 29., p – 10:23 )

Azért az tök vicces, hogy a HUP-osok arra verik a nyálukat, hogy a ZFS-nél ilyen nem fordulhat elő, erre tessék, nemcsak előfordul, de megoldhatatlan és visszafordíthatatlan adatvesztést eredményez.
Bezzeg ha külön RAID réteget használtál volna, most simán vissza tudnád állítani még a fájlrendszer ismerete nélkül is.

egy lószart tudná visszaállítani... 

most jön bzt és elmagyarázza nekünk, hogy a RAID a tuti, a zfs meg szar... mert mer írni a diszkre és elvárja, hogy amit kiír, azt vissza is tudja olvasni...

a SMR drive-ot cseszheted bármivel... normál RAIDhoz sem ajánlják... zfs esetén meg legalább fogsz tudni róla, hogy szar az adat a diszken

ha olcsó, szar a diszk, akkor cseszheted bármivel... 

ha pl. a kontroller rossz adatot ad az egyik diszkről (bit rot miatt) ... és a raid pont arról a diszkről olvas a mirrorból... akkor az appod rossz adatot fog kapni... mi több, egy scrub alatt átkerülhet ez a hiba a másik diszkre is... ergo, elcseszted (hacsak nem használtál raid6-ot)

most erre jön megint bzt és megmondja, hogy ott van a dm-integrity és miért nem használtad azt... mert rohadtul nem hatékony (amellett, hogy szar felsetupolni) és ezért nem is használja senki...

 

szóval: a snapshotok-e fontosak vagy az, hogy az adatok konzisztensek legyenek? ezt nyilván, magadnak te döntöd el

s csak megsúgom, hogy a hardware raid sem véd a bitrot ellen...

> s csak megsúgom, hogy a hardware raid sem véd a bitrot ellen...

Ezt a részletet viszont vitatom, mert van olyan hw raid ami véd a bitrot ellen.
Van vendor aki nem 512 méretre, hanem 523(?) formázza a diskeket és a 512 az adat, a többi a checksum.

Mondanom se kell a legtöbb raid vezérlőben nem ez van.

A ZFS-ben az a szép, hogy nem kell hozzá speciális/drága hardware, persze hw bugokat leszámítva jól jön az...

Ezt a részletet viszont vitatom, mert van olyan hw raid ami véd a bitrot ellen.
 

bocsánat a pontatlanságért... nyilván, van olyan hw raid, ami véd. meg a dedikált storage-ok is védenek, like netapp.

 

Van vendor aki nem 512 méretre, hanem 523

normál diszkeket meg elég nehéz úgy formázni, gondolom... szóval, azt nem a mediamarktban veszed 🤭