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.
Hozzászólások
zpool import -Ffm, végsőként pedig zpool import -FfmX ?
Áhh, ezeket már mind végigpróbáltam (lehet, hogy a többszöri -F sem segít az állapoton :/ ), mindegyik ugyanúgy disk I/O hibával fogad reggelre :(
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
-m és -X-szel is?
zpool import -v
zdb -l
?
Köszi, utóbbiból lehet, hogy ki tudok hámozni még némi többlet-infót.
Viszont - érdekes módon - a linuxos zfstools-ból v.miért a -X (még?) hiányzik. Lehet, h keresnem kell egy frissebbet.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
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!"
- '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???
Nem, linux system szinten nincsenek disk hibák. (mikor gyenge volt a táp, akkor voltak write error-ok, amik miatt sajna elszállt, de most, új táppal semmi)
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Nincs benne SMR diszk?
Ennek utána kellett olvasnom, de google szerint nincs (2-3 TB WD Green/Red)
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
A WD EFAX-ok csináltak ilyesmit.
https://blog.claryel.hu
> 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.
Ha már így szóbajött, akkor scrub-al tényleg ki lehet nyírni ezeket a diskeket? 550TB az éves workload limit egy WD Red Pro-n (bármelyik), ha hetente megy a scrub egy mondjuk 16TB-s disken az már jóval efölött van.
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.
Vanni van eltérő infóm, de remélem rossz: "New WD Red Pro "NAS" drives are rated for little more than 12 drive reads per year. So yes, monthly scrubs will eat up basically all their life." https://www.reddit.com/r/zfs/comments/whjomw/comment/ij67r5w/
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.
A scrub alapjában véve olvasás, checksum ellenőrzés. Ha hibát talál, akkor megpróbálja a paritásból/tükörből helyre állítani. Az 550TB/év terhelhetőség pedig írásra vonatkozik.